Skip to content
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

Reference annotation update does not follow soft-delete-and-add pattern #51

Open
ceesem opened this issue Apr 29, 2024 · 2 comments
Open
Assignees

Comments

@ceesem
Copy link
Collaborator

ceesem commented Apr 29, 2024

When updating annotations in "normal" tables, the annotation is marked as deleted without changing any data and a superseded_id is set to track the altered annotation. This allows time slicing and ensures data is never lost.

In reference tables, however, the data is updated in-place. This is intentional, as the code specifically has different behavior for reference tables, but this has a number of negative effects. Most importantly, old data is actually destroyed and time slicing is not possible. It also breaks the logic of live-live query, which uses the deleted tag to know to remove annotations from queried results. Neither @dlbrittain nor I could figure out a reason why this behavior should differ from regular tables.

@dlbrittain dlbrittain self-assigned this Apr 30, 2024
@dlbrittain
Copy link
Collaborator

I made some changes here:
CAVEconnectome/DynamicAnnotationDB#47

One issue is I removed the auto-update trigger so we might need to make a script to remove those triggers on the database, or have some way to migrate to the new functionality (although it is not a real migration rather back end code, but this will change behavior)

Additionally I allowed partial dicts to be passed when updating rows so you no longer have to post the entire row's data.

@dlbrittain
Copy link
Collaborator

The question remains if we want a system to automatically update the reference annotations by appending new rows when the underlying annotation row gets updated, or we can have this at the client level. Needs some pondering...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants