Extensible Storage Fields

[Anonymous]

I am looking to store a treeview of data to the extensible storage of a file. I saw in the documentation that one of the supported fields is an ExtensibleStorage.Entity, so another schema.

I am wondering can I use the same schema inside of itself, or use the same schema inside a  Map to hold all the children of the current item?

Would this be the best way to approach storing treeview data in Revit's Extensible Storage?

[jeremytammik]

Dear Michael,

Thank you for your query.

Storing instances of the schema itself inside itself recursively sounds a bit weird to me. It may make sense, though...

If you just say 'can I store a tree view of data in extensible storage', I would answer unconditionally yes.

Here is almost everything that I know on this topic:

http://thebuildingcoder.typepad.com/blog/about-the-author.html#5.23

I hope this helps.

Best regards,

Jeremy

[Anonymous]

Jeremy,

Thank you for the links. I guess my question is now if I am correct in how I am thinking about storing my data. I see that the type of data that can be stored in EStorage is limited.  I was thinking I could store it as a Map and use either a UniqueId or ElementId as the key and then a custom class as the value.  But a custom class isn't supported. I would like to use a combination of the supported types, such as ElementId and string in the value. I could theoretically break everything down to strings, but then I would lose the built-in update function of ElementId as discussed here (http://thebuildingcoder.typepad.com/blog/2011/06/extensible-storage-features.html#7).

I guess I misunderstood the use of a schema as a field in another schema. I thought (or hoped) it was a way to make a more complex data storage filed in the EStorage mechanism. In working through this then my question would be, Is there a way to make a complex data field in EStorage?

[jeremytammik · Accepted solution]

Dear Michael,

Thank you for your update and clarification.

It does indeed make sense to make use of the built-in ElementId update functionality, if that serves your purpose.

I would assume that your question is answered somewhere in the articles I already pointed out.

I also assume that you cannot add arbitrary complex data, just build it using the predefined simple data types and collections.

You can always implement a custom class to hold all your non-ElementId data and use a serialisation process to stream it into a string.

Just guessing what you are after, the simplest solution may be to use a combination of ElementId keys and a serialised string representation of a complex custom class.

I hope this helps.

Cheers,

Jeremy

[sroswurm4GJQU]

Jeremy,

I was curious to get some further thoughts from you about your comment in the last response "You can always implement a custom class to hold all your non-ElementId data and use a serialisation process to stream it into a string.".  I'm wondering if this might be the perfect solution for an issue that I've been wrangling with.  I love the potential of storing data using EStorage entities, but I dread what we might be facing if our future needs ever force the schema to change.  The thought of trying to come up with a robust and reliable update system that can replace a schema AND retain all the entity field values already assigned using the old schema seems very daunting. 

However, it occurs to me that all of this could be easily circumvented using an ultra-simplified schema having only one string field that contains a serialized custom class (i.e., using JSON or similar).  If this were the case, you could easily have a string serialized using the old class structure and if you were to deserialize it with a new expanded class structure with additional fields, all the old data would be retained and newly added class properties would simply be empty until manually populated (missing field errors could be captured with NewtonSoft.JSON, etc). 

Now I realize that this would defeat certain built-in features of the entity behavior associated with ElementIds and it would introduce the extra step of serializing and deserializing, but besides that it seems like a nice flexible solution for future growth of my complex schemas.  Do you have a philosophical or practical objection to this kind of approach?  I wouldn't want to do something that entirely defeats the intent of the schema/entity system.

[jeremytammik]

Sounds like a perfectly valid approach to me! Good luck!