Fork me on GitHub
#datomic
<
2016-04-08
>
alexmiller03:04:05

more Datomic or more Datomic books: pick one

isaac09:04:01

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.

jouerose09:04:17

@alexmiller: I want both simple_smile in due time. I think a solid 10 to 20 pager could be made as a great introduction to Datomic.

bkamphaus14:04:38

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

donaldball14:04:43

The best way to implement an entity with an ordered list of entities

jouerose14:04:51

@bkamphaus: i think you are spot on. Pacing -(we can learn from Carin Meier @gigasquid and her book "Living Clojure") - starting simple, a building block first approach.

bkamphaus14:04:01

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

bkamphaus14:04:44

@jouerose: have you seen Carin’s “Conversations with Datomic” blog posts? First one at: http://gigasquidsoftware.com/blog/2015/08/15/conversations-with-datomic/

bkamphaus15:04:40

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

donaldball15:04:49

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.

p.brc16:04:34

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:

#transactor.properties
data-dir=/var/lib/datomic
this works:
./bin/transactor -Ddatomic.dataDir=/var/lib/datomic  transactor.properties
Any ideas?

bkamphaus16:04:23

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

bkamphaus16:04:39

I’ve tested locally and it works fine for me. Not sure what’s going on in your case.

p.brc17:04:44

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

sdegutis17:04:46

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

sdegutis17:04:31

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?

stuartsierra18:04:13

That pattern is common.

stuartsierra18:04:45

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.

harold18:04:33

Is that also potentially a good place to employ the pull api?

bkamphaus18:04:10

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.

bkamphaus18:04:53

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.

bkamphaus18:04:08

Of course you can do targeted traversals that return data structures with pull and recursive specifications, etc. Just the data vs. an API. simple_smile 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.

sdegutis19:04:22

@stuartsierra, @bkamphaus, @harold: Excellent points, thanks very much all.

harold19:04:21

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

randyt21:04:52

Quick question for the listeners:

randyt21:04:08

Just trying to get my head around a migration from SQL Server to Datomic.

randyt21:04:23

Looking at onyx-etl as one possible transition tool.

randyt21:04:49

Examples for onyx-etl seem to suggest a table-by-table migration...

randyt21:04:34

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.

randyt21:04:11

anyone know if I can migrate from the SQL Server to a schema that might span multiple tables in the SQL Server?