We need to be able to make changes to schemas as the app grows without losing existing data. Firebase apps allow this through its document nature.
🎤 Pitch
Currently it is documented (and true) that deploying a collection overwrites the current data in that collection. This results in all the existing documents still existing (document ID can be found) but having no data. It seems like the default option should allow something that evolves the schema. If the new collection being posted has a new field, all existing documents get that field with its null value (required fields would obviously not be allowed). Similar, if a field is removed in the deploy than it would remove that field from all existing documents. This is the current behavior in the console, but not from the CLI.
It seems like the interface of AppWrite is set up to allow interaction as if its a document database even though its actually MySQL/MariaDB. A slightly more flexible schema like this would allow us to work more like a document database.
👀 Have you spent some time to check if this issue has been raised before?
🔖 Enhancement description
We need to be able to make changes to schemas as the app grows without losing existing data. Firebase apps allow this through its document nature.
🎤 Pitch
Currently it is documented (and true) that deploying a collection overwrites the current data in that collection. This results in all the existing documents still existing (document ID can be found) but having no data. It seems like the default option should allow something that evolves the schema. If the new collection being posted has a new field, all existing documents get that field with its null value (required fields would obviously not be allowed). Similar, if a field is removed in the deploy than it would remove that field from all existing documents. This is the current behavior in the console, but not from the CLI.
It seems like the interface of AppWrite is set up to allow interaction as if its a document database even though its actually MySQL/MariaDB. A slightly more flexible schema like this would allow us to work more like a document database.
👀 Have you spent some time to check if this issue has been raised before?
🏢 Have you read the Code of Conduct?