Fork me on GitHub
#datomic
<
2015-09-16
>
shofetim05:09:06

I have a prototype app that I'd like to run on a single EC2 t2.small instance (2 GB RAM) along wih a datomic transactor. That seems reasonable, but the transactor keeps dying with OOM errrors. Are there some knobs I can turn or is it just "transactors need at least 4GB's of RAM" ?

danielcompton05:09:31

@shofetim: there are JVM memory settings you could probably tweak

mitchelkuijpers13:09:18

Is there a way to do a sort of set operation on a entity?

mitchelkuijpers13:09:05

so that you can say on this entity only set these properties en delete everything else of this entity?

tcrayford14:09:11

@mitchelkuijpers: not that I know of inbuilt. Should be easy enough with a database function though.

mitchelkuijpers14:09:47

@tcrayford: That was what I was thinking, updates and additions are very easy though simple_smile

ericnormand17:09:06

I found what appears to be inconsistent behavior in the in-memory and the production datomic databases

ericnormand17:09:30

it has taken me a while to isolate the bug to that

tcrayford19:09:36

@ericnormand: what was the inconsistency?

ericnormand19:09:11

In a database function, I was calling coll? on a value from an entity.

ericnormand19:09:57

For a many cardinality property, the in-memory version was returning a Clojure set

ericnormand19:09:19

so (:x/y entity) => #{}

ericnormand19:09:38

but in the production version, it returns a java.util.HashSet

ericnormand19:09:25

so coll? was returning true in one and false in the other

tcrayford19:09:19

oh that's gnarly af

tcrayford19:09:03

I don't know, but I'd wager maybe the memory store doesn't even serialize segments (with fressian), just stores raw data in memory

Alex Miller (Clojure team)19:09:13

I don't think Datomic makes any commitment on the concrete data type returned there

Alex Miller (Clojure team)19:09:06

the java api javadoc http://docs.datomic.com/javadoc/datomic/Entity.html#get(java.lang.Object) says it will be a "collection" which to me means java.util.Collection

Alex Miller (Clojure team)19:09:51

not even that it must be a java.util.Set

Alex Miller (Clojure team)19:09:37

but standard caveat that I'm not on the datomic team and if you don't hear an answer here from someone on the team, feel free to ask on the mailing list

Ben Kamphaus20:09:07

@ericnormand: I can confirm that as @alexmiller mentions, Clojure collection type continuity is not guaranteed when using the API. In this specific case, it’s when passing the collection as a parameter to a database function that you see the behavior you describe (expected for current release, but the impl specific type info you see here is also not guaranteed).

ericnormand20:09:59

I'm using (instance? java.util.Collection x) now

ericnormand20:09:16

and it's actually a little simpler that way

ericnormand20:09:21

just took a while to debug

ericnormand20:09:35

it's not easy getting information out of a database function

ericnormand20:09:48

I had to package it up in an exception simple_smile

danielcompton21:09:51

@bkamphaus: sounds like that could be a good thing to put in a Datomic caveats/FAQ section if it’s not already documented.

Ben Kamphaus21:09:12

@danielcompton: documentation request acknowledged simple_smile -- I’ll discuss with the team.