Fork me on GitHub
Datomic Platonic02:03:38

@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 😛

Datomic Platonic14:03:54

@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

Datomic Platonic15:03:48

@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


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

Datomic Platonic15:03:03

@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

Datomic Platonic15:03:27

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

Datomic Platonic15:03:56

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

Datomic Platonic15:03:13

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


to be fair, I don't think @U06GS6P1N is saying that you can't model your problem domain times in datomic in this post; he's (quote coherantly imho) pointing out that using datomic's transactor time (`:db/txInstant`) for domain-event times is not a good idea, and that you could/should model domain event times using your own schema.


Confirmed, and I agree with @favila said above


Well the hype when datomic was first released was that we would finally not have all those extra time related columns all over our data. But really what datomic solves is more specific


well I would say it depends what these columns were intended for in the first place. The way I see it, Datomic is great for change detection, but not especially helpful for managing versions. People hoped for the latter, but the former is a much more common need


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