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

Ability to populate history table with insert #22

Open
sheerun opened this issue Jul 11, 2016 · 6 comments
Open

Ability to populate history table with insert #22

sheerun opened this issue Jul 11, 2016 · 6 comments

Comments

@sheerun
Copy link

sheerun commented Jul 11, 2016

Hey,

I'd like history table to contain all the data, not only modified rows. Would it be possible to add another parameter to temporal_tables, so even an INSERT to original table creates a row in history table?

@sheerun
Copy link
Author

sheerun commented Jul 11, 2016

Actually I don' even want to add sys_period to original table. I just want history table to automatically track any changes in the original table.

@arkhipov
Copy link
Owner

Yes, it is possible. Actually, that was also my first idea of how to implement system versioning, but not how the people who wrote the SQL standard decided it should be implemented. I will see if I can come up with something over this weekend.

@sheerun
Copy link
Author

sheerun commented Jul 11, 2016

You could take a look at chronomodel that uses similar approach: https://github.com/ifad/chronomodel They just version whole schema, not only a table, and it's not as integrated with postgres as temporal_tables

@arkhipov
Copy link
Owner

arkhipov commented Oct 6, 2016

This turned out to be more difficult than I expected, so I gave it up after some time. The worst thing about this approach is that when you insert a new record into the table and then update that record in the same transaction, you have to find the history record you inserted before in order to update it. So, you must have a unique constraint in the original table and the corresponding index (which includes the system_period column in addition to the columns of the unique constraint of the original table).

@mlt
Copy link
Contributor

mlt commented Jun 5, 2017

I might be late for the party, but doesn't table inheritance as described in readme solve the original problem? You'll get all records including current ones.

@arkhipov
Copy link
Owner

arkhipov commented Jun 11, 2017

I think the main point was to get rid of the sys_period column in the original table. Unfortunately, this approach comes at the price of performance loss since you will have to add two additional indices to the original and history tables and check the existence of a record any time you update it.

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

3 participants