Datomic: this is not the history you're looking for

http://vvvvalvalval.github.io/posts/2017-07-08-Datomic-this-is-not-the-history-youre-looking-for.html?t=1&cn=ZmxleGlibGVfcmVjc18y&iid=1e725951a13247d8bdc6fe8c113647d5&uid=2418042062&nid=244+293670920

by mpweiher • 9 years ago

132 18 9 years ago

vvvvalvalval.github.io

evanweaver2• 9 years ago

This is a standard bi-temporal model; valid time and transaction time are the terms the author is looking for.

We plan to add more dynamic query control over temporality to FaunaDB to solve this problem; you will be able to do a half-temporal join and get your past blog post versions by their current tags and other tricks.

valw3• 9 years ago

Thanks, it's good to know there's an established terminology. I'll do my research and update the article.

pjungwir4• 9 years ago

I saw your note in the post apologizing for making up your own terminology. I wouldn't feel too bad. In the SQL world no two authors I've read use the same terminology for these things! :-) Perhaps some terms are more "standard" than others, but they are all far from universal.

pjungwir4• 9 years ago

Temporal tables are a pet interest of mine, so here are some links that people might find useful:

Richard Snodgrass, Developing Time-Oriented Database Applications in SQL.

Hugh Darwen & C.J. Date, "An Overview and Analysis of Proposals Based on the TSQL2 Approach".

Krishna Kulkarni & Jan-Eike Michels, "Temporal features in SQL:2011".

Tom Johnston, Managing Time in Relational Databases. (I haven't read this one yet.)

Tom Johnston, Bitemporal Data.

Magnus Hagander, "A TARDIS for Your ORM": https://www.youtube.com/watch?v=TRgni5q0YM8

Also I've yet to see anyone even talk about managing DDL changes in temporal databases (well Magnus mentions that he won't cover it), but it's the same problem as discussed here. It's very practical, but you could write a dissertation or a book about it.

evanweaver2• 9 years ago

Temporal DDL is the reason why FaunaDB late binds validations and indexes.

It decouples the history of the schema from the history of the data, and migrating the past is not very practical anyway.

eriknstr• 9 years ago

If you could add links for the papers you mentioned that'd be nice. Assuming they are available to the public.

jeffdavis2• 9 years ago

Also Temporal Data and the Relational Model https://www.amazon.com/gp/aw/d/B005UY0W0E/ref=mp_s_a_1_1?ie=...

A great book which inspired Range Types in PostgreSQL: https://www.postgresql.org/docs/current/static/rangetypes.ht...

gphilippart• 9 years ago

This issue was discussed in the Datomic google group back in 2012. I think a satisfying solution was found in the end. https://groups.google.com/forum/#!topic/datomic/zDoFsxKgARQ. Also, there's this blog post: http://blog.podsnap.com/bitemp.html

valw3• 9 years ago

Thanks!

moomin• 9 years ago

It's a very important distinction though. Arguably Datomic is missing the point here, which is that t_truth and t_recorded are often different. My classic example of this is an accounting system. Sometimes you want to know "what was the P&L on Dec 2016?" sometimes you want to know "what was the P&L on Dec 2016 believed to be on Dec 2016"? And sometimes you want to do differences between the two: e.g. Dec2016 using Dec2016 facts vs Dec2015 using Dec2016 facts.

Both are equally important, but Datomic blesses one and not the other.

owebmaster2• 9 years ago

The problem 1 he describes would be solved with software engineering. Schema migration is a complex issue. It is funny that he asked the intern to do this part. Bad article.

valw3• 9 years ago

Right, I forgot, curating editorial content is best done via software engineering :) what was I thinking?

owebmaster2• 9 years ago

If you need to do a HUGE schema migration in a running software, for sure. If it wasn't a running software, put it as a Datomic problem is even more juvenile.

Datomic: this is not the history you're looking for

Related Stories