Fork me on GitHub
Ramon Rios11:07:00

Hello everyone

Ramon Rios11:07:44

Syntax error (Exceptions$IllegalArgumentExceptionInfo) compiling at (datomic_utils.clj:1:1).        
:db.error/not-enough-memory (datomic.objectCacheMax + datomic.memoryIndexMax) exceeds 75% of JVM RAM
Did someone pass through this before when initialzing datomic?


Do those two settings together exceed the Xmx of your JVM?


Or maybe your Jvm Xmx is too small?


I wouldn’t even try to run a peer with less than 2-3g Xmx. There’s a lower limit where it won’t start at all, but I don’t remember where that ends up being

Ramon Rios11:07:47

I increased heap memory

Ramon Rios12:07:06

Still have this issue


what is your xmx, datomic.objectCacheMax, and datomic.memoryIndexMax?

Ramon Rios12:07:07

I'm trying to find it

Ramon Rios15:07:08

I resolved updating my java version

Ramon Rios15:07:31

I had a too old java


I created a small Clojure lib/script to do (some of) the right things to upload a jar file to a S3 Maven repo. Folks using dev-local may find it useful. You can paste it into a bb script if you want it to go a bit faster.

👍 6
Drew Verlee18:07:18

Does qseq lazily get all the entities? or is that eager and only the datomic/pull and xforms are lazy?

Drew Verlee18:07:33

From the reading its eager

Drew Verlee19:07:26

I take it he absence of a lazy datomic query means thats a very hard problem. As in if you can't get lazyiness on something involving joins (and not just an index).

Alex Miller (Clojure team)19:07:33

I think you are assuming things that are not necessarily true

Alex Miller (Clojure team)19:07:09

but I am not in a place of enough knowledge to answer definitively

Alex Miller (Clojure team)19:07:20

conceptually, there is nothing about joining per se that prevents "laziness"


> Item transformations such as pull are deferred until the seq is consumed.


I believe qseq only performs the work in :find (e.g. pulling) lazily. There’s still an eagerly realized query result set back there with all the values for the vars referenced by that find


correct me if I’m wrong, but that was my understanding of the tradeoff qseq gives you


that sounds coherent


time to first thing is reduced, still a full query done on the remote end


also explains “efficient count”--i.e. because it’s really backed by a set


When querying for an entity that contains a :db/valueType of :db.type/ref, what is the proper Datalog syntax for pulling attributes from the child entity? Does that have to happen as a two step query (i.e. pull the parent with the ref value, then pull the attributes on that ref entity that you want) or is there way to accomplish the fetching of attributes from a ref entity in a single query?