New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve deletion via LTX zero commit #382
Comments
Sorry if this is too obvious, but I want to highlight this case. In my use case, a new database can be recreated with the same name as a deleted database, but it has no relation to the old one except for using the same name. Case: |
The filename is the only identifier for the database in LiteFS so the two databases are related in that sense. On the LFSC side, you'd still see an entry for the database after deletion but it wouldn't show up on the LiteFS side if the database size was set to |
If I delete and recreate a database with the same name, will it cause any problems? And if I delete it again, will it affect the previous deletion? |
No, it shouldn't cause any problems. With LiteFS, a transaction represents a specific set of bytes that make up the database at a given point in time. By making a zero-length database represent a deletion, it's just another transaction from LiteFS' perspective. So internally, the TXID will keep incrementing even though you've created/deleted multiple times. e.g.
|
@gc-victor I implemented soft delete so you can actually delete databases while connected to LiteFS Cloud (#395). You can test it using the Docker image for the PR: COPY --from=flyio/litefs:pr-395 /usr/local/bin/litefs /usr/local/bin/litefs |
Great! I will test it next week. |
Currently, LiteFS communicates database deletion to replicas by sending a "dropdb" frame in the stream. However, this doesn't work well for LiteFS Cloud as it acts as the data authority and doesn't receive a stream. LFSC also needs to retain old copies of the database in case of recovery in the future.
This issue is to track the integration of "zero commit" LTX files (superfly/ltx#46) into LiteFS & LFSC.
The text was updated successfully, but these errors were encountered: