Hi, Sebastian.
Is there any documentation regarding schema versioning and how to set it up / handle it in squidex?
Thanks!
There is no versioning really. Every content always uses the last version
If you are consuming the API, in your consumer app you may maintain different versions of the schema connector/plain-old object/API access layer and then interpret the data however you like.
In MongoDB BSON databases, it is not necessarily important that you migrate existing records to new versions of the schema until it is necessary by your application; and, unlike with SQL RDBMS databases, this migration does not occur automatically upon the ALTER TABLE analogue nor can it be done atomically and consistently within a single transaction.
Squidex builds on MongoDB concepts, which uses a BASE design which differs from the ACID design. As a general rule of thumb, most SQL databases approach their design using an ACID goal; whereas, most noSQL databases approach their design using a BASE intention instead.
Consider the AWS documentation highlighting the differences. ACID vs BASE Databases - Difference Between Databases - AWS (amazon.com)
You might prefer something like this schema versioning pattern, if versioning is important for you; you simply add a field for your schema version:
Maintain Different Schema Versions - MongoDB Docs
If versioning is not necessarily important, you may simply use null checks to ensure that your data is in a valid format needed to render the data to the consumer, or you may transform it within your consumer app to, for example, a view-model instead. MongoDB is very loose with collection schemas in the same way JavaScript is very loose with variable data types.
1 Like