I also do the same and I have not noticed any problem

Same

only thing to keep in mind, is that, even if nothing changes, there will still be an empty transaction created (a single datom), and that will show up in the history DB - if you start he application a lot (several times a day), then that can add up to a lot of datoms over time...

Ah interesting, that I didn't know

No

You should think more about consistent values for a unit of work than about the expense of creating a db object: https://docs.datomic.com/on-prem/best-practices.html#consistent-db-value-for-unit-of-work

also by passing down a db you guarantee that the entire subtree of function calls cannot transact

(so you don’t have to worry about accidental writers)

Yes too crazy because of concurrency

Thank you. Could you be so kind and expand on that a little? Do you mean it breaks when concurrent access is attempted? I don't think I have any concurrency there..

You’d have to guarantee that the lambda is not being concurrently called

At which point it would be better to just use datomic proper or ddb

Well, the lambda is run once a month by a schedule so I wouldn't worry about that. Yeah, dynamodb is much bette choice but then I don't get to learn Datomic 😢

Because of the VAET reverse lookup index, there's no major performance impact here either way I think, provided you write your :where clauses properly. think about how you'd write the query for each case (have child find parent, have parent list children, etc.), and you'll see they work out about the same.

thanks...what would be 'improper' :what clause in this case? I'm asking exactly because query-wise there's no difference

oh I just meant the usual principles of writing your :where clauses so that they (a) start as specific as possible, and (b) always have overlap between one line and the next, so you don't get a big cross product.

you're right, it doesn't really matter which way around you model the relationship, the where clause is just swapped around.

got it. I typically navigate to specific 'child' node from the 'master' so was thinking that maybe it's more efficient to have the ref on the child

it's worth noting: if the children are :db/isComponent and should be deleted if their parent is deleted, then you want a list of children refs on the parent.

how about

[:find ?parent ?child
:in $ ?param ?child-param
:where 
[?parent :some/attrib ?param]
[?child :has/a ?parent] ;; or the other way round
[?child :other/attrib ?child-param]

yes, I really don't see what difference it could make

that's perfectly fine. what you want to avoid is this order:

[?parent :some/attrib ?param]
[?child :other/attrib ?child-param]
[?child :has/a ?parent]

but that's a general query design thing and doesn't really have anything to do with 1-n relationships.

yes you are right. my thinking is still SQL influenced sometimes and I get weird feelings and need to double-check

I'll remark, finally, that the "parent with list of children" approach actually makes a n-n relationship, in principle. it's just a coincidence if every child appears in the list of exactly one parent. having a :db.cardinality/one parent attribute on each child makes it certain that it's 1-n.

good one, this is important if I need to enforce restriction. thanks!