Fork me on GitHub

@marshall @jaret — hey folks. we sometimes get a delay from this codepath: what could cause tx-range to return a delay rather than [] or nil?


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


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


can you give any insight, please?


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


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


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 ?


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


@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


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


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


i think you’re right


@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


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?


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


I sort-of referring to but I can't remember where I read that there's some advantage to grouping wrt. storage and index compation


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


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


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


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


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.


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


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


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


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


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}}


got it, and you’re right