Fork me on GitHub

Any harm in transacting a schema multiple times?


I transact on every application start (even on elastic ones)

👍 3

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

Jake Shelby22:11:26

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


I transact on every application start (even on elastic ones)

👍 3
Michael Stokley16:11:29

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


You should think more about consistent values for a unit of work than about the expense of creating a db object:

🙏 3

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

👍 3

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

Jakub Holý (HolyJak)18:11:42

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!


Yes too crazy because of concurrency

Jakub Holý (HolyJak)20:11:29

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

Jakub Holý (HolyJak)20:11:32

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 😢


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

Braden Shepherdson18:11:49

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

Braden Shepherdson19:11:53

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.

Braden Shepherdson19:11:47

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

Braden Shepherdson19:11:42

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

Braden Shepherdson19:11:39

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]
because that finds all plausible parents, and all plausible children, and then finally just the intersection.

Braden Shepherdson19:11:59

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

Braden Shepherdson19:11:27

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!