It is better to attach the parent to the children rather than the children to the parent because that enables referencing in both directions.

i.e. zou can then select the children using the inversion syntax (:_<attribute>) in pull expressions. also, if a child needs to be removed, the parent entity does not need to be updated.

hans you can walk refs both direction

nxqd: i use it for basically all state storage

bvulpes: sure. but with an 1:m relationship, it is better to put the "1" into the "m"s rather than the other way round.

i suppose it depends on how frequently you'll be walking which direction, and how much you like typing underscores

but that's kind of glib

I agree it depends a lot on your use case. I do the opposite of what hans recommends, because I need multiple parents pointing to the same children, without modifying the children

I also end up typing a lot of underscores, though

is it true that Tx size can affect query performance?

found this thread from 2013 which seems to indicate that: https://groups.google.com/forum/#!searchin/datomic/performance/datomic/ijZV-PKTCQc/-yGSEViwJUUJ

suggests it's best to keep Txs in 1-45kb range. However one would think this only matters for writing transactions

hi - do people run the transactor in a docker image?

for dev purposes

@jonpither: Hey Jon. Yes, I know several folks run Datomic in docker containers. Not sure about dev vs. production, though. The guys at PointSlope had a blog post with a basic rundown of running the transactor in a docker container: https://pointslope.com/blog/datomic-pro-starter-edition-in-15-minutes-with-docker/

In the docs for the query grammar, the grammar for inputs is ':in' (src-var | variable | pattern-var | rules-var)+, but shouldn't it be ':in' (src-var | variable | pattern-var | rules-var | binding)+?

inputs can specify bindings, right? (http://docs.datomic.com/query.html#sec-5-7)

thanks @marshall