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.
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.
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):
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.
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.