Fork me on GitHub

How to sort and limit result in datomic query? I saw seek-datoms, but it seems that can only query one attribute?


I have this database function where I require a namespace in my own project, using the requires syntax. This is working when using the in memory database, but not in one that is backed by a Cassandra base.


Do I need to put the namespace on the transactor classpath somehow to make it work?


@casperc: yep, see the second paragraph for create a function here:


@bkamphaus: I have read it and I don’t think it explains the issue very well. It just says to use require or imports, but not how to get that that code loaded in the transactor


Can you elaborate what should be done?


jar in the lib subdirectory of the Datomic distribution, i.e. datomic-pro-0.9.5350/lib - I can re-read and see if we need to add it.


@bkamphaus: Ok thanks. I guess it makes it a bit harder to use. I think it makes more sense to define the functions in the scope of the code block then (even though that is a bit ugly)


And regarding the docs, IMO the documentation is quite weak for database functions, so I think it could use a brush off with some more examples, e.g. with a :require in there.


Thanks for the swift answer though simple_smile


I can take a look at improving the dbfn docs. I will say, that it’s not a path that we want to be too encouraging simple_smile but maybe we can document that to some extent as well.


there aren’t a lot of use cases for dbfns outside of a transaction function, and transaction function uses should be really limited — i.e. when you need to guarantee ACID isolation and can’t do so with a builtin like cas and an optimistic concurrency strategy.


@bkamphaus: Well maybe there is a better way to do what I am doing then. simple_smile I have made a replace-entity function, which takes an entity id and a new “version” of the entity which should replace the old. The function makes retractions for the fields that are not present in the new version and updates the fields that are still present - cardinality many attrs are retracted and new values are inserted.


@bkamphaus: So it is a CAS-like functionality. Actually I would have expected it to be a built-in, since would seem like a fairly common use case in my mind.


I would say what you’re doing matches the transaction function use case fine. When you say “CAS-like” do you mean it should fail on update from time of submission, or is the transaction written so that it should ignore any updates made (i.e. implicit retract) between transaction submission and write time?


@bkamphaus: Well actually no, it’s not really cas-like come to think of it. It only updates the current entity with a sort of “overwrite” semantic on the current entity.


So it uses the current database value to see which adds and retracts it should make, but doesn’t really compare and fail if the value is not the expected like cas


But doing it in the peer would allow for a race condition i believe


yep, it matches the transaction function use case shape pretty well, so I think your approach makes sense.


@bkamphaus: On a different note, I read your blog post about AlphaGo and the previous one. I liked them simple_smile


I am trying to get a grasp of deep learning so I appreciate your approach of trying to address obstacles when looking into it


glad to hear you’ve found it to be worthwhile reading. The way I find it helpful to think about it is frequently different than what I see in my own reading and research, so I’m happy to write the posts as an exercise in understanding for my own benefit. I’m doubly glad if anyone else gets anything out of it.


I definitely plan to continue with the deep learning theme and touch on other frameworks, probably at the same 1-2 post/month rate for now.


Sounds good, I’ll keep an eye out then.