This is result of a small research on what may happen when two Strapis with slightly different content types share one database. This may happen when we want to deploy Strapi instances with slightly different content types in two different deploy slots.
- Strapi 3.0.0-alpha.17
- using MySQL (version is hardly relevant)
When we change content type with content type builder in Strapi admin page, it changes only api/*/models/*.settings.json file.
This file seems to be read only in the bootstrap phase. Strapi saves what it reads from the file to the DB table core_store with the value of corresponding JSON and with the key db_model_*. After this phase Strapi seems not to read the file at all and read only from the DB.
When the frontend app makes get or post request, Strapi itself doesn't seem to validate the data. The frontend app will get JSON stringified version of table rows whether or not the data conform to the content type that is on core_store table. Posted data are directly translated into SQL insert query and the DB will complain when the query doesn't conform to the table structure which will lead to 500.
Strapi changes api/*/models/*.settings.json and adds the column in the table in DB. Existing rows will be filled with default value.
Strapi changes api/*/models/*.settings.json but DOES NOT remove the existing column. The response of a get request from frontend still holds the field before we delete the column from the table.
Strapi will respond with 500 when the frontend makes a post or put request that holds the deleted field.
Strapi changes api/*/models/*.settings.json. Instead of changing the name of the column, it adds another column with the new name and keeps the old column. The value doesn't move from the old column to the new one.