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.
Hint: 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, views, and access rights. For latter you need to simply inform the users and trust in their cooperation.
Check it out
Check it out
The most difficult part of the schema change is code that breaks. Such errors can ultimately only be decteced during runtime. But Topincs supports the administrator to better anticipate potential effects by schema changes. All schema changes are type related. On the subject page of each type you find a usage tab. This tab list how many topics or statements of this kind exist and the soure code positions where the type is used. These are exactly the locations where a runtime error would occur, if you delete the type. Domain classes can also be of help during remodelling.
This page cannot be displayed in your browser. Use Firefox, Opera, Safari, or Chrome instead.
Saving …