This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-10-04
Channels
- # aleph (3)
- # beginners (37)
- # boot (45)
- # carry (1)
- # cljsrn (15)
- # clojure (78)
- # clojure-austin (2)
- # clojure-brasil (10)
- # clojure-czech (3)
- # clojure-dev (12)
- # clojure-dusseldorf (31)
- # clojure-hamburg (2)
- # clojure-italy (4)
- # clojure-poland (2)
- # clojure-russia (37)
- # clojure-spec (25)
- # clojure-uk (30)
- # clojurescript (160)
- # cursive (40)
- # data-science (1)
- # datomic (31)
- # emacs (7)
- # figwheel (4)
- # hoplon (73)
- # leiningen (1)
- # liberator (5)
- # luminus (7)
- # numerical-computing (1)
- # off-topic (31)
- # om (89)
- # onyx (66)
- # proton (5)
- # protorepl (1)
- # re-frame (18)
- # reagent (2)
- # ring (2)
- # spacemacs (1)
- # untangled (93)
- # vim (19)
- # yada (67)
@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?
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
thank you @marshall, as always!
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
neither the seq
nor take
should introduce a delay
so I would look at Datomic
ok Thanks @alexmiller 🙂
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.
@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 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
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