Clojurians Log v2

Any harm in transacting a schema multiple times?

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

is calling d/db to create a db from a conn expensive?

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)

Hello! I would like to start playing with Datomic. I have this project, clj_tumblr_summarizer , that will run monthly as AWS Lambda, fetch fresh posts from Tumblr, and store them somewhere for occasional use. Now I would like the "somewhere" to be Datomic. It is far from the optimal choice but I want to learn it 🙂 So my idea is to use dev-local and storing its data to S3 (fetch it at the lambda start, re-upload when it is done). My question is: Is this too crazy? Thank you!

hi, is there any performance or other difference how 1-n relations are implemented? refs 1 --> n or the other way round?

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!

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 😢