datomic

Ask questions on the official Q&A site at https://ask.datomic.com!
hanDerPeder 2020-11-16T10:03:38.415500Z

Any harm in transacting a schema multiple times?

tvaughan 2020-11-17T15:47:55.436100Z

Same

Jake Shelby 2020-11-20T22:45:26.467200Z

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

vncz 2020-11-22T01:17:12.469900Z

Ah interesting, that I didn't know

vncz 2020-11-16T13:43:04.416Z

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

2020-11-16T16:14:29.416500Z

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

favila 2020-11-16T16:29:00.416600Z

No

favila 2020-11-16T16:30:59.416800Z

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

1🙏
favila 2020-11-16T16:31:50.417100Z

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

1👍
favila 2020-11-16T16:32:06.417300Z

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

Jakub Holý 2020-11-16T18:07:42.421200Z

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!

gdanov 2020-11-16T18:10:34.422900Z

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

2020-11-16T18:59:49.423200Z

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.

gdanov 2020-11-16T19:01:04.423400Z

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

2020-11-16T19:01:53.423800Z

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.

2020-11-16T19:02:47.424Z

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

gdanov 2020-11-16T19:03:09.424200Z

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

2020-11-16T19:03:42.424400Z

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.

gdanov 2020-11-16T19:07:08.424700Z

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]

gdanov 2020-11-16T19:07:53.424900Z

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

2020-11-16T19:08:39.425100Z

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.

2020-11-16T19:08:59.425300Z

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

gdanov 2020-11-16T19:10:10.425500Z

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

2020-11-16T19:12:27.425700Z

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.

gdanov 2020-11-16T19:13:43.425900Z

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

ghadi 2020-11-16T19:20:09.426500Z

Yes too crazy because of concurrency

Jakub Holý 2020-11-16T20:08:29.426700Z

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

ghadi 2020-11-16T20:41:46.428Z

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

ghadi 2020-11-16T20:42:17.429100Z

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

Jakub Holý 2020-11-16T20:49:32.429300Z

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 😢