moose icon indicating copy to clipboard operation
moose copied to clipboard

handle drop table condition on dev restart

Open cjus opened this issue 11 months ago • 2 comments

A long description of a data loss scenario I ran into:

Last night, I used the latest build to construct a test scenario for work on this migration PR. I ran into an unexpected situation and suspected I was missing something.

Here's what I did.

  • I pushed records into my local Clickhouse DB into UserActivity_0_0, which worked as expected.
  • I then modified the data model for UserActivity by adding a new field, and I updated the package.json version and project.toml version with the new git commit ID.
    • All good there.
  • I restarted the moose docker-compose by shutting down the stack and restarting with moose dev
  • I then inserted new records into UserActivity_0_1, and that worked as expected.

I wasn't expecting that my records from UserActivity_0_0 would be missing and migrated to UserActivity_0_1. I understand there's a trigger in place, but I thought that was a copy and not a move operation.

cjus avatar Mar 23 '24 23:03 cjus

After running a test I determined that the data loss occurs during a simpler path:

  • Create a new moose project
  • Push records to the newly created UserActivity_0_0 clickhouse table by using the senddata.sh script or curl if you like. I sent 10 records in my test.
  • Now simply edit the app/datamodels/models.prisma file and update the UserActivity data model.
  • At this point the file watcher detects a change to the model and drops the UserActivity_0_0 table causing the data loss of my 10 records.

Note a key point in the test above is that the moose server was not restarted during the model change. Had the server been stopped and restarted then the records would have been properly migrated into the new table.

cjus avatar Mar 24 '24 00:03 cjus