Extensible Storage - best practices with plug-in development & growth

[adam.krug]

I'm currently developing a Revit plug-in and need to utilze a Schema, for now, I will just need two bool fields. However, the plug-in will grow over time and eventually will become a ribbon with multiple buttons & various functionality. Thus I assume that at some point I might need more sophisticated Extensible Storage. I already know that once a Schema is built, it cannot be extended, what is then best practice in such situations? To have separate Schemas for each part of my plug-in?

[aignatovich]

Hi!

Some people store data in serialized form (such as JSON).

I don't thing, that it is good practice. Imagine, your app v1.0 requires 2 piece of data: A and B, and your app v1.2 requires 3 piece of data: A, B and C. Your v1.2 app reads storage and see, there is no C. What does this mean? Was it due to old data or C should not be present? Your next app v.1.3 requires new data format for B -> B', may be with old data structure. Again you should deal with ambiguity environment, moreover, your app v.1.3 may deal with 3 data formats: (A, B), (A, B, C) and (A, B', C).

To deal with such thing you should have data version information and build specific processor for each version:

(A, B) -> v1.0 processor, that for example asks user about C and transfer data for the next processor

(A, B, C) -> v.1.2 processor, that converts B to B' using some algorithm

(A, B', C) -> just use data to do useful things.

Since schemes could not be changed, specific schema with it's id works as version mark. It has strongly typed fields and it is rather comfortable to use it. Your task as a software developer is just to organize your code, encapsulate details and don't repeat yourself. Prohibition of scheme modification is good thing in my opinion.

[David_Robison]

Not being able to modify schemas does become a problem as your add-in becomes more complicated.

I store everything in map fields, like this:

builder.AddMapField("strings", typeof(string), typeof(string));
builder.AddMapField("ints", typeof(string), typeof(int));
FieldBuilder field = builder.AddMapField("doubles", typeof(string), typeof(double));
field.SetUnitType(UnitType.UT_Custom);
builder.AddMapField("bools", typeof(string), typeof(bool));

These fields allow me to change what I am storing without modifying my scheme. The first value I always add is a version to the ints. When I get my entity from an element, if it's not there, I know I need to add it and do any initialization. If it is there, I check the version, and do whatever upgrades are necessary if it is not the most recent.

[adam.krug]

It seems like having these four dictionaries (strings, bools, ints, doubles) should be enough to handle every possible data. If you need other types you can derive them from these four one way or another.

I really like this idea, it's more generic from aignatovich's yet still it enables version control.

Thanks for sharing David.Robison & aignatovich!

[a_minet]

Could you provide an example please, with versioning?

[ranusami5]

I'm in the process of developing a https://bestlaptopsexpert.com/ Revit plug-in, and I'm grappling with schema management. Initially, I only require two boolean fields, but as my plug-in grows, it's apparent that I'll need more sophisticated Extensible Storage. I'm aware that once a schema is created, it cannot be extended, so I'm seeking advice on best practices for handling this situation. Should I consider creating separate schemas for different parts of my plug-in to accommodate future growth, or is there a more efficient approach to schema evolution in Revit that I should be aware of?