This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (7)
- # aws (5)
- # beginners (37)
- # boot (39)
- # cider (4)
- # clara (2)
- # cljs-dev (32)
- # cljsjs (1)
- # cljsrn (12)
- # clojure (235)
- # clojure-austin (3)
- # clojure-belgium (7)
- # clojure-berlin (11)
- # clojure-dev (36)
- # clojure-france (10)
- # clojure-japan (10)
- # clojure-poland (2)
- # clojure-russia (39)
- # clojure-uk (4)
- # clojurescript (81)
- # code-reviews (9)
- # core-async (6)
- # core-logic (1)
- # datomic (32)
- # editors (7)
- # emacs (1)
- # hoplon (191)
- # jobs-discuss (14)
- # juxt (4)
- # lein-figwheel (4)
- # leiningen (3)
- # off-topic (7)
- # om (49)
- # onyx (34)
- # other-lisps (1)
- # overtone (11)
- # parinfer (1)
- # proton (5)
- # re-frame (11)
- # reagent (12)
- # spacemacs (2)
- # untangled (90)
- # yada (15)
Why Datomic do not support alter fulltext attribute. At the beginning of our project, we need not fulltext search on a attribute. But now, we want it.
@alexmiller: I want both in due time. I think a solid 10 to 20 pager could be made as a great introduction to Datomic.
@jouerose: what’s the hardest thing to discern from docs/group etc. that you’d want to see addressed in a book? Or is it more a general wish for a certain tone and pacing of introduction?
@isaac: it has to do with the overhead of creating and maintaining the fulltext index. The fulltext index is also eventually consistent, and sort of a small step outside of Datomic’s model.
@jouerose: have you seen Carin’s “Conversations with Datomic” blog posts? First one at: http://gigasquidsoftware.com/blog/2015/08/15/conversations-with-datomic/
@donaldball: I think solutions vary. It's admittedly not easy with Datomic schema at present. Explicit ordering attributes, linked lists via ref attrs, strings - probably more typical approaches.
Sure, I was just suggesting that as a topic for a book chapter. It’s dead simple in most rdbms and is a common requirement, yet solving it correctly in datomic seems to require either learning about transaction fns or recursive rules.
I see a weird issue, the transactor does not seem to honour my data-dir setting via the transaction.properties. But when I set the property directly via the (undocumented?) system property datomic.dataDir it works fine. Interestingly HornetQ is able to pick up the setting from the properties file just fine and writes its server.lock into the configured directory. So this does not work for me:
./bin/transactor -Ddatomic.dataDir=/var/lib/datomic transactor.properties
@p.brc which version of Datomic are you using and where is it putting data instead? I’m assuming you’re using dev/free and talking about where it’s writing the db dir with the h2 files? and that transactor has permissions to access it? (seems implied by it working with command line arg).
I’ve tested locally and it works fine for me. Not sure what’s going on in your case.
@bkamphaus: I am using the latest pro with cassandra. Strace tells me that it is trying to write indexer data relative to the distribution base directory into ‘data/indexer/$UUID’ which is AFAIK the default.
Is it common to write code like this, in order to get a bunch of entities from a query?
(->> (d/q '[:find [?entity ...] :where [... clause goes here ...]] db) (map #(d/entity db %)))
Or is there an easier or less redundant way to get entities from a query? Or perhaps should getting entities from a query be less common than I'm thinking it is?
When defining functions, I find it useful to put just the "query" part in its own function definition. That makes it easier to reuse the query in other ways.
Definitely possibly a fit for pull expressions. Using a pull expression ( http://docs.datomic.com/query.html#pull-expressions )doesn’t provide the same separation of concerns for the select and project portions that @stuartsierra mentions, but it’s a good fit if you want all the data (or a particular kind of data) for the entities in question and don’t plan on otherwise repurposing that query.
The reason to potentially prefer entity in @sdegutis case over pull would be laziness. I.e. the entities I retrieve from the query are starting points from which I will traverse an entity graph.
Of course you can do targeted traversals that return data structures with pull and recursive specifications, etc. Just the data vs. an API. Coupled with the other usual concern here about keeping the things a query does simple and composable vs. expressing as much as you can in a single declarative query.
Excellent elucidation Ben, lazily pulling with
d/entity could be a huge advantage (assuming you're in a situation where you don't consume the entire sequence - no sort, etc...).
If transitioning this db to Datomic, my initial assumption is that they schema would likely be very different from the relational manifestation of this data.