topic Re: Extensible Storage - best practices with plug-in development & growth in Revit API Forum

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

adam.krug — Wed, 06 Jun 2018 11:44:14 GMT

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?

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

aignatovich — Wed, 06 Jun 2018 12:47:58 GMT

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.

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

David_Robison — Thu, 07 Jun 2018 09:49:30 GMT

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.

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

adam.krug — Thu, 07 Jun 2018 10:23:48 GMT

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!

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

a_minet — Wed, 12 Jul 2023 13:54:33 GMT

Could you provide an example please, with versioning?