@marshall Brilliant! We'll look into it.

When datomic connection with sql database and :datasource, the first used datasource will be cached and after that, all call will route to first datasource. It's fine with normal jdbc str, but it didnot work with :datasource.

Just to check, has anybody open sourced a Datomic exporter to other (SQL) databases? I've asked before, but hoping someone wrote one since then 😛

@marshall If custom txInstants can't come before the first timestamp in the database, should we start everybase with an init transaction in 1900 or so? Sorry if I didn't understand the docs correctly.

@clojurians873 custom txInstants cannot come before the last tx's instant, i.e. they must be strictly increasing

the point being if you're recreating a db of past transactionss, you need to be careful to transact in a historical order

@favila ah, that makes sense actually. Sounds like we should be viewing databases more as temporary artifacts that could be reconstructed from data at a whim, rather than have a single 'common source of truth' database.

you need a source of truth somewhere

but the use case here is constructing easier-to-use derived views of whatever that source of truth is

@favila interesting

for example, you could have a source-of-truth datomic db where tx is time of record and you explicitly model problem domain times

but every once in a while for analysis you can generate another db from that one where the tx time is the problem domain time

so as-of and since views of this db exactly correspond to a reconstructed record of historical events

@favila interesting idea... i'll ponder that for a bit. We're basically pulling from kafka and other log sources because they're in some cases too large to put in datomic

@favila good idea on the problem domain time...

https://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

(sorry for the spam), but the above post by some guy had us scared for a bit, but your solution sounds like the best

in the post he basically says you can't model your problem domain times in datomic, etc

well imagine git had no force-push

it's kind of like that

txInstance is commit time, but the data in the commit may have other times

if you got a date wrong in a git commit, you make another commit to fix it; you don't alter the original commit and force-push