@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.

What is the best way to implement a limit or paging functionality in Datomic?

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

Why can't benchmarks be disclosed