Clojurians Log v2
datalevin
Why datalevin-native 0.9.12 is not on clojars ? And again no Linux ARM version...
Ahh my bad, didn’t see the -native part. 🤷
Yess... I need for GraalVM compilation
because I didn't think people are using it.
we are very behind in graalvm version, so I thought people were not using it.
another reason is that clojars kept rejecting it for its large size. I don't have time to cut it down. Maybe I need some help here.
Sending org/clojars/huahaiy/datalevin-native/0.9.12/datalevin-native-0.9.12.jar (20493k) to https://repo.clojars.org/ Could not transfer artifact org.clojars.huahaiy:datalevin-native:jar:0.9.12 from/to clojars (https://repo.clojars.org): transfer failed for https://repo.clojars.org/org/clojars/huahaiy/datalevin-native/0.9.12/datalevin-native-0.9.12.jar, status: 413 Request Entity Too Large
posted in #clojars voice your concern there too if you care about it
Ok. Thank you for answer
But what do you mean "very behind"? There is version 0.9.11... is it different from common 0.9.11?
I mean the version of GraalVM we require is very behind compared with the latest version.
Ahhh. I see, 22.3.1 instead of 23
that's the reason why clj-lsp dropped us
I don't have time to update it, because it requires code change on my part.
I welcome contribution.
Ok, I'll take a look maybe on weekend
0.9.12 native is pushed.
I see! Thank you
Is there a reason that empty is not supported on datoms? A user has reported an issue with Cursive (https://github.com/cursive-ide/cursive/issues/2970), the issue seems to stem from an exception which contains a datom in its ex-data. Cursive uses clojure.walk over the ex-data, and this fails because walk uses empty.
No reason. We can add an empty function, and always return false, how's that sound?
Sounds ok to me, although I don't really understand the semantics of datoms - whatever you think is reasonable is fine by me.
Would you like me to file an issue for this?
sure. thanks
Thanks!
Note that empty returns a new collection of the same type (but empty), unlike empty? which returns a boolean
Yep, that's why walk uses it, so that it can rebuild the collections with the returned value from the function you pass it. Whether that makes sense for datoms, I'm not really sure.
resolved
Is it the known behaviour that any future with Datalevin query inside d/with-transaction hangs up the application on deref?
(require '[me.raynes.fs :as fs] '[datalevin.core :as d])
(let [dtlv-dir (fs/temp-dir "dtlv-sandbox")
conn (d/get-conn (str dtlv-dir))
tr-data (into [] (map #(array-map :entity/id % :entity/uuid (random-uuid))) (range 1000))]
(try
(d/transact conn tr-data)
(d/with-transaction [cn conn]
(let [odds (future
(d/q '[:find [?e ...]
:where
[?e :entity/id ?id]
[(odd? ?id)]]
(d/db cn)))]
(println @odds)))
(finally
(fs/delete-dir dtlv-dir)
(d/close conn))))There's no transaction inside with-transaction. Why would one do that?
It's simplified example..
I wound't have a future in with-transaction, what does that even achieve?
the basic idea of a transaction is to group a set of actions as an atomic thing. Put a future in there violate this basic assumption.
I wouldn't even think about this. So, it's not a known issue, but it is also a wont-fix
put a with-transaction inside a future, that's fine, we have lots of tests for those cases.
maybe I understand something wrong about with-transa ction? How I see it: Inside with-transaction block I have something like database "sandbox". So I can do transactions and queries in the block and be sure that nothing outside it will change the state. In the end of with-transaction all changes are flushed to persistence. Isn't it? My idea is to achieve more functional purity for every user request. To be sure that for certain pair of request and database state the result always will be the same...
I am not sure about the "sandbox" idea, but the work a read/write transaction does to the DB is not visible outside the transaction until the transaction commit. True. However, it has implications. a LMDB read/write transaction has to be done with a single thread, so putting a future in there is asking for trouble.
maybe it can be made to work, but that's not something I want to support.
Okay, now I see
Need to work in one thread
because semantically, a transaction should be able to abort and roll back, if some work is done in another thread in a future, how's that going to work?
Yes, that makes sense
What is behind such behaviour? This query work nice as expected:
(d/q '[:find ?n
:in $ ?uid
:where
[?e :test-entity/user [:user/id ?uid]]
[?e :test-entity/data ?n]] (dtlv) (:user/id user))(d/q '[:find ?n
:in $ ?uid
:where
[?u :user/id ?uid]
[?e :test-entity/user ?u]
[?e :test-entity/data ?n]] (dtlv) (:user/id user))What’s stuck?
Second one never completes... calculating forever. Need some research to find out minimal example to reproduce...
Thanks
Could be a bug . These two went into completely different code paths. The first one has only one entity class, the second has two.