During the life cycle of a software project requirements change since organizations are not rigid and static but dynamic and flexible. At least some. There is various reasons why changes occur and for software development the only thing that matters is that change will happen and we want to be prepared for it and keep the cost as low as possible.
This section explains what you need to look out for when you need to change the data schema. Only real changes are considered a change: topic types and constraints need to be replaced by others. Adding new constraints and topic types does not cause any problems in Topincs. It can be done any time while the database is in use.
There is three types of schema consumers in a Topincs system: human users entering information, instance data and source code components using the virtual API. All of them are affected by changes in the schema in different ways.
Human users may get confused, but are generally flexible to enough keep functioning. They will become active, complain, and ask for training.
A schema fragment is a collection of topic types and constraints. It has no digital cohesion, but is only grouped in the mind of the administrator performing the transformation.
If there is already statements in the database that conform to the current schema, it will be invalid after the schema change has been performed. Thus it needs to be transformed. In the period of change both schema fragments need to be present. The old one is deleted after the transformation of the instance data with a service has been completed.
Since Topincs allows instance data to be recorded while the schema is under development, it is advisble to constrain the users either technically or organizationally to use only the stable part. Prior is done by by using index configuration and views. For latter you need to simply inform the users and trust in their cooperation.
The most difficult part of the schema change is code that breaks. There is currently no aid from Topincs apart from exceptions emailed to the administrator during runtime. If this is too late for your use case, you need to review all source code components and check whether they use the API powered by the old schema fragment. Domain classes can be of help in this case.
This page cannot be displayed in your browser. Use Firefox, Opera, Safari, or Chrome instead.