Fork me on GitHub
Stel Abrego04:05:29

If anyone is interested in the upgrade process from Hiccup 1.0 to 2.0, I just wrote a PR for liquidz/clj-vimhelp that does this. The PR makes it much easier to interact with the library due to the better escaping semantics of Hiccup 2.0:

👍 2

Are there any known resources explaining why datomic is only partially persistent instead of fully persistent? Just curious what the challenges would be in making it fully persistent.

Alex Miller (Clojure team)14:05:13

this might be better asked in #datomic or, although the first question might be - what does "partially persistent" mean? I'm not familiar with that being a term that Datomic uses to describe itself.


Thanks, I'll post there Alex. I found it while reading this PDF - > Fully persistent data structures are the most common type used in functional programming > languages. On the other hand Datomic is currently only partially persistent because one can only > modify the newest version [1]. > Which seems to make sense with what I've read, IE while you can query the history of facts using time, you cannot modify these past versions, only modify the present one.


sounds like not a great fit for a database

👍 1

What is the definition of "modify" in the context of immutable data structures? :thinking_face:


I think in terms of datomic, it'd be like transacting against history - creating some additional history branch off of that.

👍 1

> sounds like not a great fit for a database Agreed, was just hoping perhaps the compromises / trade-offs were discussed at some point in a talk perhaps

Joshua Suskalo18:05:50

just off the top of my head it just sounds like a mess. There would be no real idea of what the "present" is, since at any time you could walk back (along any branch) to any arbitrary transaction point and add a new branch. If a database is designed to allow you to keep a single point of truth for data stored across multiple applications, making it branch in time breaks that.


I think it makes sense, since that is what git does. I just think it isn't something a lot of people need, and adds complexity, so why bother?

Linus Ericsson06:05:50

During tests, a branchable db is helpful. This can be done in memory using "Branching of reality" can be accomplished by things like tagging transactions, like this video from Tim Ewald on reified transactions: Otherwise, checkout bitemporality, like XTDB has: