This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-02-15
Channels
- # aatree (23)
- # admin-announcements (13)
- # announcements (3)
- # beginners (49)
- # boot (50)
- # braid-chat (1)
- # braveandtrue (37)
- # cider (72)
- # cljs-dev (25)
- # cljsjs (6)
- # cljsrn (37)
- # clojure (78)
- # clojure-berlin (8)
- # clojure-greece (1)
- # clojure-ireland (2)
- # clojure-madison (14)
- # clojure-new-zealand (2)
- # clojure-poland (10)
- # clojure-russia (149)
- # clojured (2)
- # clojurescript (49)
- # community-development (6)
- # core-async (37)
- # cursive (1)
- # data-science (1)
- # datomic (30)
- # emacs (4)
- # euroclojure (1)
- # funcool (1)
- # graclj (1)
- # hoplon (17)
- # jobs (2)
- # jobs-rus (45)
- # ldnclj (6)
- # mount (12)
- # off-topic (124)
- # om (270)
- # onyx (131)
- # parinfer (70)
- # perun (2)
- # proton (168)
- # re-frame (32)
- # reagent (29)
- # ring-swagger (8)
- # testing (9)
- # yada (39)
@val_waeselynck, @bkamphaus thanks for helping. i have done the same thing, I do sorting by using sort-by
and paging by partition
and take
hi guys, can't we use a rule like this in datomic : [[(rule-name rule-arg) [(not (< rule-arg 0.5))]]
@nxqd: this looks like a similar case to what was raised here: http://stackoverflow.com/questions/32164131/parameterized-and-case-insensitive-query-in-datalog-datomic — function expressions in datalog don’t nest.
@bkamphaus: yeah it seems so. I think I will try to solve the problem on the returned data instead of from datalog for now.
@nxqd: sorry, may have read too quickly. You should be able to make rules using negation and disjunction, though I haven’t put together a rule like that any time recently that I remember. Of course, in the example you provide, you can negate < with >=
@bkamphaus: I'm not sure If I remember correctly or not that we cannot apply nested clauses in datomic ? just make sure I understand things correctly
you can’t nest function calls. not
, not-join
, or
, and or-join
, though specify negation and disjunction which apply to the clauses that follow them, which is a different case. They have an inside/outside e.g. not
vs. the default and
-like behavior in datalog.
@bkamphaus: thanks
@bkamphaus: is it safe to use db.with()
on a memory database value after the mem connection which created was released or deleted ?
very likely not
@val_waeselynck: that’s definitely on the edges of my knowledge — have you already encountered issues doing this or are you checking prior to attempting? I’ll have to look into it, just helpful to know context of my doing so beforehand.
I had an issue where my auto-reloaded tests would complain about a database having been released, but haven't been able to reproduce
so mostly checking prior to attempting
let me rephrase it: it's worked for me so far, but maybe it's only because I have been lucky
Does Datomic provide any access to its' transaction expansion? I want to fully expand a transaction (tx functions, tx maps) into the final tx that the transactor will invoke (`[ [:db/add :e :a :v :tx] ...]`) so I can do some pre-validation work before allowing a transaction to go through.
I suppose I could try to cram all conceivable logic into a db transaction, but I'm trying to keep it out of there.
I don't need the real-time tx, just what it would be if executed at that point in time... that is enough for me to do my pre-work.
@bplatz: not at present. It is a feature that’s been requested and I can note your interest in it. https://groups.google.com/forum/#!searchin/datomic/transaction$20map$20form/datomic/9D6zZYkiGlw/hc06dtalyS0J — it is a fairly simple transform as noted here: http://docs.datomic.com/transactions.html#map-forms — "Each attribute, value pair becomes a :db/add list using the entity-id value associated with the :db/id key."
Tx functions are the ones I'm more concerned about. Nested entities/refs as well, but those aren't too bad.
@bplatz: a transaction function called with datomic.api/invoke
instead of in a transaction will return its transaction data (rather than transacting it).
so... assuming I have [[:db.fn/retractEntity [:person/email "
, I'd look at the tx for two-element vectors, then call (d/invoke db (first v) (second v))
? And I assume I'd do that in first-to-last order of the transaction, assuming I need to do that for multiple functions?
I guess it is like macro-expansion... so probably each function invocation I start the parse over from scratch.
And I'm just trying to be specific to make sure I replicate what Datomic does internally, else it doesn't achieve the goal. Thanks.
Actually just realized there can be multiple params passed to a function, so scratch the first/second comment. So just wrapping up my logic, the order I'll look to implement is (1) expand all maps with :db/add
, (2) look for any tx function (where first vector element is not :db/add or :db/retract) and use (d/invoke db ...)
. (3) repeat step 2 to look for more functions, stop when no addition functions are found.
I guess just doing paging an a query doing a (pull ) is a bad idea since it is pulling a bunch of data up front, so should I find the entities, filter/page and then pull?
@casperc yes I usually run a query to find the entities ids Im interested in, then convrt them to entities, sort, paginate, then map a function which converts them to maps (or whatever format the client needs)
@val_waeselynck: so you use the d/entity function to get the entity before paginating? Is that fast enough?
well as we all know i cant disclose any benchmark :) but this approach has worked for me so far. I dont believe entities have a lot of overhead since theyre lazy and whatever segment they live in has been loaded in the previous query