[HN Gopher] Bitemporal History
       ___________________________________________________________________
        
       Bitemporal History
        
       Author : r4um
       Score  : 36 points
       Date   : 2021-04-08 05:03 UTC (17 hours ago)
        
 (HTM) web link (martinfowler.com)
 (TXT) w3m dump (martinfowler.com)
        
       | thelittlenag wrote:
       | I ran across this notion for the first time when I started a job
       | in finance a few years back and as an interview question they
       | asked me about it. I hadn't heard of the notion and so afterwards
       | tried to find some good resources online to read up about it.
       | 
       | What I found was not great. So glad to see this idea getting a
       | good write up.
        
       | nyanpasu64 wrote:
       | Reminds me of rebasing Git branches in order to clean up commit
       | histories, or rewriting Git repositories in order to change
       | usernames/emails stored inside.
       | 
       | I just hope that whatever systems get created (bitemporal
       | history, version control, etc.) have support for "replacing"
       | previous usernames, or deleting events prior to a specific
       | "record time" and replacing them with newer understandings of
       | history. Doing so in Git (a more-or-less append-only system)
       | results in multiple histories which diverge at the moment of the
       | change.
        
       | helsinki wrote:
       | I have not read the article, but I have written a bi-temporal
       | ORM, and I find it to be such a useful concept in practice. One
       | of the primary benefits is optimistic locking. You can say
       | goodbye to explicitly locking during a db transaction.
        
         | yamrzou wrote:
         | This sounds interesting, could you please share more details
         | about it? (or the source code if available)
        
       | jacobobryant wrote:
       | Shout out to Crux (https://opencrux.com/), a bitemporal database.
       | I've been using it for a year now and it's fantastic.
        
       | amboo7 wrote:
       | In simpler cases, you can see the problem as purely functional
       | data structures.
        
         | maldeh wrote:
         | And for the rest of us there's always ConcurrentSkipListMaps.
        
         | refset wrote:
         | More specifically, retroactive data structures[0] are an
         | interesting lens for thinking about bitemporality. After
         | watching some great Erik Demaine lectures on temporal data
         | structures I wrote a bit about the relationship to
         | bitemporality on the Crux site[1].
         | 
         |  _> In summary, the Crux indexes as a whole could be described
         | as a  "partially persistent and fully retroactive data
         | structure"._
         | 
         | Although thinking about it now Crux also supports proactive
         | (i.e. future) operations, so I should probably correct that!
         | 
         | [0] https://en.wikipedia.org/wiki/Retroactive_data_structure
         | 
         | [1]
         | https://opencrux.com/articles/bitemporality.html#_retroactiv...
        
       ___________________________________________________________________
       (page generated 2021-04-08 23:00 UTC)