What I think is that you are confusing the schema_version and user_version pragmas. user_version is what you would use to keep track of which migrations have run and it can be safely updated (or not updated) without…
manually updating the schema_version can lead to database corruption https://www.sqlite.org/pragma.html#pragma_schema_version If you are willing to risk corrupting the database, then yes you can trick rust-query
Author here: I just wanted to point out that rust-query does in fact read the schema from the database and compares it to the expected schema. There is no checksumming or comparison of migrations. It is checked…
sqlite has `STRICT` tables that are statically typed
You (and many other commenters) are right that rust-query currently requires downtime to do migrations. For many applications this is fine, but it would still be nice to support zero-downtime migrations Your argument…
Sending row IDs to your frontend has two potential problems: - Row IDs can be reused when the row is deleted. So when the frontend sends a message to the backend to modify that data, it might accidentally modify a…
Hi, migrations are 1 select statement + `n` insert statement for `n` rows right now. This might be improved to insert in batches in the future without changing the API.
What I think is that you are confusing the schema_version and user_version pragmas. user_version is what you would use to keep track of which migrations have run and it can be safely updated (or not updated) without…
manually updating the schema_version can lead to database corruption https://www.sqlite.org/pragma.html#pragma_schema_version If you are willing to risk corrupting the database, then yes you can trick rust-query
Author here: I just wanted to point out that rust-query does in fact read the schema from the database and compares it to the expected schema. There is no checksumming or comparison of migrations. It is checked…
sqlite has `STRICT` tables that are statically typed
You (and many other commenters) are right that rust-query currently requires downtime to do migrations. For many applications this is fine, but it would still be nice to support zero-downtime migrations Your argument…
Sending row IDs to your frontend has two potential problems: - Row IDs can be reused when the row is deleted. So when the frontend sends a message to the backend to modify that data, it might accidentally modify a…
Hi, migrations are 1 select statement + `n` insert statement for `n` rows right now. This might be improved to insert in batches in the future without changing the API.