You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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...
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.
The text was updated successfully, but these errors were encountered: