`DROP TABLE` leads to corruption?

[louwers]

Once a table has been turned into a CRR with crsql_as_crr, dropping it seems to result in irrecoverable corruption since the crsql_changes will be in an invalid state. Deleting changes is not possible (only inserts are allowed).

SELECTing from crsql_changes now leads to query aborted. If the table is dropped and re-created on two sites, trying to sync will fail whenINSERTing old changes that are lingering (could not find row to merge with for tbl ....

I think when dropping a table, all related entries in crsql_changes should be deleted.

[louwers]

SELECT crsql_begin_alter('mytable');
DROP TABLE mytable
SELECT crsql_commit_alter('mytable');

Results in:

Error: failed compacting tables post alteration

[louwers]

OK deleting mytable__crsql_pks and mytable__crsql_clock seems to resolve the issues.

But since these are not part of the API of cr-sqlite, I think these tables should be dropped along with the source table automatically. But I think this is a known limitation right now:

cr-sqlite/py/correctness/spec.md

Line 29 in 0d62b52

4. [ ] drop table

[tantaman]

Thanks. I'll update begin_alter to account for drop table