Writing to one field overrwites all fields?!

I have created a Schema with 3 fields.
Two string fields and one dictionary field.

If I write to the first string field and dictionary field it works.
Yay…

However… If I then add to the first field it seems to wipe the dictionary field.
image

What am I doing wrong?

Scripts attached
StringAndDict << creates Schema and adds fields + data
AddString << attempts to update the string field only

StringAndDict.dyn (34.9 KB)
AddString.dyn (26.8 KB)

I asked ChatGPT and it told me this:

In Revit’s Extensible Storage, when you set a new Entity to an element, it overwrites the existing one.

Is this correct? I can’t just amend a field?!!

Isn’t this the same issue you had here?
Setting a field in extensible storage removes the other fields from the entity - Developers - Dynamo (dynamobim.com)

Extensible storage is not a data management architecture. It doesn’t work like parameters or properties or dictionaries or anything else you might be used to. It’s just “dummy storage”. Whatever you write to it is what gets stored. If you want to add or modify something you need to write the full “block” of data to storage. The data itself can use hierarchies and relationships in whatever format you like, but the entity itself is just a copy of that data. It does no retain its relationship with the element.

1 Like

Yeah, realised that… Bit of a shock. I thought it was a writable database (as in, fields are editable independently).

I’m doing separate schemas with 1 field each instead… Easier to work with.

It can be if you plan on using extensible storage that way. Typically, you just have a read all and a write all function for your schema, so you’re always dealing with the entirety of your data set.

I thought about that but decided separate would be easier for me.
Two of the fields are just lists of strings.

1 Like

Think I said this last time, bu tI’ll try to clarify further.

I set the door’s mark parameter to 1, and then set it to 2, the previous value of 1 is lost. Which is exactly what is happening with the entity.

Like parameters there is no such thing as “append” for an entity, only “get” and “set”. The first time you set the entity you set it to something like this:

("a string", {"First": "Jacob", "Last": "Small"})

The second time you set the entity you set it to something like this (although unintentionally so):

("a string", null)

Yep… I got that for 1 field.

But if I alter field #1 it overwrites field #2 and field #3 at the same time :expressionless:

The fields aren’t part of the entity, they’re part of your dataset (within the entity). Your entity is just a container and you always provide a new container.

You can store 3 binders (with recipes for breakfast, lunch, and dinner respectively) in a box. If you pull out the lunch binder and add a recipe, you would just put that binder back into the same box and your recipe “database” would be updated. This makes total sense logically because the recipes in the binders in the box are a structured system. Extensible storage doesn’t work like that. You’re not adding data to the box. You’re providing a new box. If you pull out a binder to update, you need to also pull out the other binders if you want the new box to contain all your recipes.

… but I want it to work like that said in a moaning voice :stuck_out_tongue:

I was wanting to store issue data in the model… but kinda worried how easy it is to wipe now.

Like issuance information for every individual element? Might be easier to have containers for each issuance with lists of elements rather than individual entities for each element.

Sheet issues in a specific format.

Harder than wiping the parameter value for ‘issued by’, or any other parameter value in the model, as users have to have the add-in to edit it.

Instead of using a generic ‘set’, write a custom function to read, then append new, and finally set. :slight_smile: