Fork me on GitHub
#datomic
<
2016-10-04
>
robert-stuttaford08:10:05

@marshall @jaret — hey folks. we sometimes get a delay from this codepath: https://github.com/onyx-platform/onyx-datomic/blob/0.9.x/src/onyx/plugin/datomic.clj#L309. what could cause tx-range to return a delay rather than [] or nil?

robert-stuttaford08:10:28

the delay takes the form of "#object[clojure.lang.Delay 0x5201a90 {:status :pending, :val nil}]”

robert-stuttaford08:10:59

it may be that onyx-datomic’s use of seq over the result of d/tx-range is leaking a delay out

robert-stuttaford08:10:06

can you give any insight, please?

marshall13:10:59

@robert-stuttaford the use of seq would be my guess as well

marshall13:10:30

@robert-stuttaford looking again - there’s also a take read-size which could be doing it

zamaterian14:10:20

Hi whats the default query consistency level (com.datastax.driver.core.ConsistencyLevel ) when using datomic on top of cassandra ?, and is there any way of seeing the defaults the datomic uses when configuring the datastax driver ?

robert-stuttaford15:10:50

is that not perhaps a bug, @marshall? i can’t imagine a situation where getting a delay like this is a worthy outcome, given the documented behaviour

marshall15:10:53

@robert-stuttaford yeah, i’m not sure - it might be worth asking @alexmiller and/or the onyx team in the clojure and/or onyx rooms; If it is indeed related to Datomic itself I’m happy to elevate it, but I’m not sure whether it’s Datomic or not

Alex Miller (Clojure team)15:10:39

neither the seq nor take should introduce a delay

Alex Miller (Clojure team)15:10:46

so I would look at Datomic

robert-stuttaford15:10:07

great, thanks @alexmiller and @marshall — let me know if you need me to participate in some way

Ben Kamphaus16:10:40

@marshall and @robert-stuttaford I believe the premise in Onyx documented as: "relies on the fact that tx-range is lazy” is not true.

marshall16:10:51

i think you’re right

lucasbradstreet16:10:51

@bkamphaus: that is useful to know that it is not lazy, and we may rewrite how it's used. However, should that affect whether a delay is returned or not? I would expect it to always return maps or always return delays

malcolmsparks16:10:16

Here's a quick question re. idioms - I know that it's common to have attributes namespaced with the type of the entity that 'belong' to, e.g. :customer/id, :department/id. I find this is a bit limiting in a few situations. For example, you might have a number of 'nouns' in your system and want to express a general relationship between them, like :like, :has-favorite. Is it considered OK to have a single universal attribute for public uuids, e.g. :global/id for this use-case?

malcolmsparks16:10:35

I've read there are storage downsides but I'm not sure what they could be

malcolmsparks16:10:24

I sort-of referring to http://docs.datomic.com/best-practices.html#group-related-attributes but I can't remember where I read that there's some advantage to grouping wrt. storage and index compation

malcolmsparks16:10:53

Does anyone here use 'global' attributes for a few things?

Ben Kamphaus16:10:47

@malcolmsparks the main impact is query, where e.g. you can’t use :person/has-favorite to only consider people, so [?p :person/has-favorite ?f] becomes [?p :person/id][?p :global/has-favorite ?f] (you have to join a clause that filters people instead of limiting to entities of interest with one clause).

Ben Kamphaus16:10:04

may be others as well, but I’ve found query paths in large dbs that walk through a globally namespaced attribute tend to be performance bottlenecks in many cases (though sometimes restructuring the query or re-ordering it can significantly reduce the impact).

malcolmsparks16:10:21

@bkamphaus ah I see, that helps. In this case there aren't going to be many datoms with :global/has-favorite, the problem we've found is locating entities via lookup-refs to create transactions. Without a global key it complicates the code to create a generic 'has-favorite' relationship.

malcolmsparks16:10:19

I guess in our case with relative few :global/has-favorite datoms the attribute index would help a lot with performance. Plus, with unique attributes of course there's a index on uuid values.

misha19:10:18

@malcolmsparks: same here: I went with global :g/id for the ease of creating stuff +, maybe, sync with datascript. But system is not in production, so I did not get any regrets yet.

jfntn19:10:24

Is it possible to specify that an eid should resolve to its ident with the pull syntax?

bhagany21:10:15

@jfntn: no, unfortunately, if you want the ident you’ll need to specify it in the pull expression

jfntn21:10:01

hmm that actually sounds like what I want, not sure I understand?

bhagany21:10:20

well, it’s a nesting level down from what I understand you to want - you’d want to get {:ref/to-ident :your /ident}, but what you’ll get is {:ref/to-ident {:db/ident :your/ident}}

jfntn21:10:26

got it, and you’re right