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)

@robert-stuttaford good point.

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 https://github.com/walmartlabs/vizdeps ?

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?

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

or @marshall here

(I’m not it :)

@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