Here we use a general programming language to describe a specification of data which we then use the concept of instanciation to then create variations of this model specification in ram. In order to save these variations of the specification between program instanciation we must transfer their data to long term storage.
We may state that all instances will have custom values to fill the fields specified, instances do not often have the ability to override the behaviour of functions from their class.
An example is production description using production processes
So we can use this model at our program runtime to instanciate instances, we then may have bespoke ui to edit these elements such as the production process or we can use autogenerated ui. When wanting to continue into the future with these definitions we must save them to a type of long term data store.
Updating data to changing formats
IF THIS IS COOL IT WILL NOT ONLY UPDATE THE TOP LEVEL DATA STORED IN A LTDS BUT WILL ALSO BE ABLE TO UPDATE DATA STORED WITHIN THE TOP LEVEL DATA NON TOP LEVEL DATA STILL PRESENTS THE SAME PROBLEMS AS TOP LEVEL DATA
When altering the specification our data in the long term stores could possibly be made invalid. Within the currently planned Bulk data editing actions if we held in some capacity the knowledge of what had changed and what versions the data was created on, we could queue up some bulk actions such as the addition of a new attribute to a certain value, removal of all values, setting some named data to the value of other named data. There are problems with this, it relies on us having external knowledge of what our selected data is and the new format.
We could make this process at least semi automatic by having knowledge of what specification each piece of data is conforming to To do this we must store a reference with the data or store a reference in the specifiction name. I think it is best to store an id seperate to the specification name I could store a version number that counts upwards or I could store a uuid. I am currently defining the specification in the code. I will always have to have the specification represented in the data instances in the code provided that it follows a similar structure to python. I am defining the specification in my coding language and therefore I would like to not redefine it elsewhere. This means that when the code changes I would like to store versions of either that file or the specification that I can then reference in the data created by it. If I were to implement versioning for data in a long term data store then I could store the code in a long term data store and use that system to version the code also
Versioning data in a long term data store How to store code using a long term data store What does using this method mean for data created from specifications that are not versioned using your system. Well if we are purely versioning by ltds versioning then no types but those present in a ltds can be versioned and we must not store a version value for any data not in a ltds. I think this is ok.
If modelling using data type instances within a custom language, then a big opposing force is the rigidity of systems constructed around your modelling method to change. These need to be dealt with. Systems constructed around modelling include:
- the users point of interaction with creating the models such as a gui design
- instances following the protocol of the model