Fork me on GitHub

How are you all structuring your code for database functions? I assume: have small interfaces in datomic and put the rest of the code on the classpath of the transactor?


Cheers @timgilbert! Very useful 🙂


@stijn i really dislike that approach because it means regular transactor downtime (every time you have code to deploy)


transactors should be as disposable and hands-off as possible


e.g. using cognitect's AMIs, where it's hard to pull in extra dependencies


@favila excellent. thanks!


@uwo Note that those peers are still able to write to the Datomic instance (i.e. submit transactions), as that work is handled through peer->transactor->storage


ah, of course. so, that configuration would be somewhat pointless, then? @marshall


it probably isn’t a terrible idea just in the sense that your peer user creds are less open


but it wouldn’t result in a ‘read only’ peer


Ah I misunderstood what you were after @uwo. With respect to storage, all peers are read-only. But there's no way to turn off their ability to submit txs to the transactor


yeah. I wasn’t thinking through clearly.


incidentally, I believe ‘read only peer’ would be appropriate as a feature request in our portal - I’d suggest you add it there if it’s not already in there


thanks, request made.


It looks to me like com.datomic/datomic-pro "0.9.5561" depends on org.apache.httpcomponents/httpclient "4.5.2" which depends on commons-codec "1.9". But com.datomic/datomic-pro "0.9.5561" also depends on commons-codec "1.5" directly, overriding httpcomponents' dependency and forcing the older 1.5 version of commons-codec. Is this right? Is it good? What is the reasoning? If the code in datomic-pro is compatible with commons-codec 1.9, then I think removing the direct dependency on 1.5 is a good idea.


Are there any performance improvements to be gained by using enums for attributes that are in some sense bounded? For example, I have a lot of data that needs to be retrieved by day (in the bi-temporal sense, not the t). Indexing millions of entities by day seems wasteful if the universal set of days is bounded to a few years, e.g. :as-of/+20170622 is not too cumbersome to use. Basically, will I get the same query performance swapping out indexes for enums?


@harold: I've just added a [commons-codec "1.10"] top-level dependency to my project.clj in order to pin the dependency, personally (I'm extra-paranoid about class-loading conflicts)


@timgilbert - that sounds dicey too, if httpcomponents depends on 1.9 specifics the change you suggest could break it (same for datomic and commons-codec 1.5, and datomic's explicit direct dependency suggests to me that it does depend on 1.5 specifics).


I agree, but to me that diceyness is a lot more palatable than the diceyness of "include two copies of these classes in the classpath and let the fates decide which version the JVM will load on each invocation"


FWIW, from the changelog of commons-codec it looks like largely just bugfixes in more recent versions


@timgilbert - If you use lein it's not as bad as that. On a related note, have you seen ?

Alex Miller (Clojure team)20:06:42

lein or mvn will pick one, not include both (but that one might not be the one you want)


Oh right. Well, build-time uncertainty is better than run-time uncertainty, but not by that much


@alexmiller - any thoughts on this conflict? Is there a better place to report/post it?

Alex Miller (Clojure team)20:06:43

if you have a Datomic support account, those channels are fine


@alexmiller - Oh, didn't think of that. I don't interact much with the datomic licensing stuff we do. Thank you.


@harold we'll look into that. I'll get back to you with findings


jaret: Sounds good. I'm not on this slack much, feel free to email me at <mailto:[email protected]|[email protected]> if I can be of service.