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

versioning of data #337

Open
klarareder opened this issue Nov 2, 2018 · 5 comments
Open

versioning of data #337

klarareder opened this issue Nov 2, 2018 · 5 comments
Assignees
Labels
other SzenarienDB WP category requirement_specification Pflichtenheft specification_sheet Lastenheft Time-L High estimated time to work off, voted on in project meeting Urgency-S urgency level: small

Comments

@klarareder
Copy link
Contributor

As a user, I want to access old versions of data if I accidentally entered something wrong.

@klarareder klarareder added the specification_sheet Lastenheft label Nov 2, 2018
@christian-rli
Copy link
Contributor

This cannot be fully achieved within the current project. Generally speaking this is possible - by hand. A user interface would be too complicated. In emergency situations @MGlauer can recover old versions, but this can only be a last resort and is not meant to be a regular service so far. For the time being there should be a notice somewhere communicating as much.

RequirementSpecificationID=62

@christian-rli christian-rli added requirement_specification Pflichtenheft Urgency-S urgency level: small Time-L High estimated time to work off, voted on in project meeting labels Jan 28, 2019
@christian-rli christian-rli added the other SzenarienDB WP category label May 14, 2019
@han-f
Copy link
Contributor

han-f commented Aug 13, 2019

May this be a potential use-case?
I upload a table that successfully went through the review. It now lives not in model_draft but in its "final" schema. This table however contains data that may periodically or sometimes need amendments (i.e. lines to be added). How can this be made possible?

@christian-rli
Copy link
Contributor

@Ludee and I are currently finalizing a first data set of the kind you described @han-f here. Our idea was to handle curation in a GitHub issue. We will still need to streamline the process of implementing contributions, but the general idea seems viable.

@MGlauer
Copy link
Contributor

MGlauer commented Sep 29, 2020

There will be a notice describing the current state. There will be no specific interface to access different versions (yet).

@jh-RLI
Copy link
Contributor

jh-RLI commented Apr 4, 2024

Firstly, we could simply implement the advice/notice mentioned in the comments above


As this is relevant again and we have talked about versioning on several occasions.

Currently our revision system is in operation. It keeps track of all user transactions (all C-R-UD changes) and stores them in a schema called, for example, "_model_draft" if the original table is in "model_draft". If a user then creates, updates or deletes data in the table, the changes are saved as a delta. To go one step further and calculate the versions of it, we would need a system that can track the changes related to a version.

This type of solution is relatively complex, especially since our current data publishing workflow would allow for a simpler solution:

The user has to upload the data while it is in the theme / schema model_draft. For this reason, I think we could create a new version every time the user publishes the data. That is, it would be necessary to provide an "upload new version" button or something else next to a "published" table. Then we only need to track the new upload & save the previous version and don't need to calculate the deltas for each version.

This solution seems simpler to me, but may not be mature enough yet. There may also be other advantages if we choose the more complex solution.

@jh-RLI jh-RLI assigned wingechr and jh-RLI and unassigned MGlauer Apr 4, 2024
@wingechr wingechr removed their assignment Sep 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
other SzenarienDB WP category requirement_specification Pflichtenheft specification_sheet Lastenheft Time-L High estimated time to work off, voted on in project meeting Urgency-S urgency level: small
Projects
Development

No branches or pull requests

6 participants