spring-data-jpa-temporal
temporal_tables
Our great sponsors
spring-data-jpa-temporal | temporal_tables | |
---|---|---|
2 | 16 | |
2 | 886 | |
- | - | |
0.0 | 4.2 | |
almost 2 years ago | about 1 month ago | |
Groovy | C | |
Apache License 2.0 | BSD 2-clause "Simplified" License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
spring-data-jpa-temporal
- spring-data-jpa-temporal: a lightweight temporal auditing library
-
What is the point of all these new Java versions when Java 8 is all that seems to be supported by most apps?
Can I ask something? I recently started working on a library (this) using Java 16 but I had hoped on supporting minimum Java 8 (since it's a Spring extension and Spring supports Java 8).
temporal_tables
-
All the ways to capture changes in Postgres
There is also the temporal_tables extension.
-
Show HN: I made a CMS that uses Git to store your data
- https://github.com/arkhipov/temporal_tables
I haven't used any of these but I work on https://xtdb.com which is also implementing SQL:2011's temporal features :)
-
Data point versioning infrastructure for time traveling to a precise point in time?
It seems like PG has this extension here anyone ever use it?
- How Postgres Audit Tables Saved Us from Taking Down Production
-
spring-data-jpa-temporal: a lightweight temporal auditing library
All good. Note there is also https://github.com/arkhipov/temporal_tables/ (which is also type 4 as a postgres extension - pretty similar to what ebean orm is doing)
-
Time-travel options for databases
The Temporal Tables Postgres extension works well. https://github.com/arkhipov/temporal_tables
-
SQLite the only database you will ever need in most cases
One of postgres's most underrated features. RLS is amazing, can be unseen/basically work silently if your programming language-side tools are good enough, and is documented well (like everything else):
https://www.postgresql.org/docs/current/ddl-rowsecurity.html
But the power of PG is that it doesn't stop there, if you combine this with a plugin like temporal_tables and you can segment by user and time:
https://github.com/arkhipov/temporal_tables
All of this mostly unknown to the thing that's accessing the DB. If that's not enough for you, why not add some auditing with pgaudit:
https://www.pgaudit.org/#section_three
I think it might not actually be hyperbole to say that Postgres is the greatest RDBMS database that has ever existed.
- Temporal Tables PostgreSQL Extension
-
Bitemporal History
I haven't used `temporal_tables` but I have built similar temporal systems on Postgres in the past. (Judging by https://github.com/arkhipov/temporal_tables#usage at least.)
The trouble with these sorts of approaches is that they solve temporality the same way we did in the 90s: Add an `entity_history` table, timestamp your tx-time and valid-time, and add a trigger to version your entities. This must be done for each entity you want to version across your temporal plane.
It would appear that `temporal_tables` doesn't support bitemporality yet. It only has tx-time (system time). But even if it did, this approach doesn't help you with live data. Because the `entity` table corresponding to the `entity_history` table still permits destructive updates, temporal queries are always in the realm of audits and can't answer questions about the application data directly. Add to that a completely manual system of querying the temporal information, and the resulting systems tend to get quite hairy, which is why Martin recommends avoiding bitemporality whenever you can. Unfortunately, that recommendation (while sound, for relational databases) means that bitemporality is expensive and manual if and when it's implemented.
A bitemporal database like Crux encodes the temporal plane into all the data stored in it, making it transparent to the user. There's no up-front setup cost to bitemporality and a query's default time on both time axes is "now", allowing the user to ignore temporality entirely except in those few instances where it is required -- but when it is required, it is global.
Related to bitemporality, I'd be curious to hear whether anyone has experience with the Temporal Tables[1] extension in PostgreSQL?
What are some alternatives?
TimescaleDB - An open-source time-series SQL database optimized for fast ingest and complex queries. Packaged as a PostgreSQL extension.
pg_bitemporal - Bitemporal tables in Postgres
pgaudit - PostgreSQL Audit Extension
dolt - Dolt – Git for Data
datasette - An open source multi-tool for exploring and publishing data
beekeeper-studio - Modern and easy to use SQL client for MySQL, Postgres, SQLite, SQL Server, and more. Linux, MacOS, and Windows.
debezium - Change data capture for a variety of databases. Please log issues at https://issues.redhat.com/browse/DBZ.
Reladomo - Reladomo is an enterprise grade object-relational mapping framework for Java.
Sonarr - Smart PVR for newsgroup and bittorrent users.
xtdb - An immutable database. Developed by @juxt
rust_sqlite - SQLRite - Simple embedded database modeled off SQLite in Rust
periods - PERIODs and SYSTEM VERSIONING for PostgreSQL