Fork me on GitHub
#datomic
<
2020-12-02
>
oxalorg (Mitesh)13:12:53

I'm trying to add a child entity with a ref to a parent entity using a lookup-ref

(d/transact conn {:comments/title "foo" :comments/article [:article/title "bar"]})
But I have incomplete data of B. So sometimes there is no article called "bar". This gives me a :db.error/not-an-entity error. How would I go about writing this query so that if "bar" does not exist then only add the child "foo" but keep it's :child/parent attribute as empty?

pithyless17:12:43

@U013MQC5YKD 3 common ways to go about this: 1. Change the [:article/title "bar"] to {:article/title "bar"}. Assuming :article/title is unique and :comments/article is a to-one relationship, this won't throw the error, but will either use the existing article or create a new article (with just that attribute). 2. If you don't want to create a new (possibly incomplete article), you need to query the db for existence before doing the transact and modify the transaction accordingly. 3. If you're querying the DB to check for existence and then doing a transact, this may lead to a race-condition. If this is important to avoid, you can instead create a custom transaction function and move the check for existence within the transactor. This will guarantee that you don't have a race-condition (your transaction function will check for existence of the article and then transform the transaction data accordingly before committing).

🎉 3
oxalorg (Mitesh)07:12:31

Thank you so much pithyless, this was of great help! I'm going to try these out and see what works for me. 🙂

plexus14:12:43

I'm setting up Datomic Analytics for a client, and am running into an issue with BigDecimal

{:type "java.lang.ArithmeticException",
   :message "Rounding necessary",
   :suppressed [],
   :stack
   ["java.base/java.math.BigDecimal.commonNeedIncrement(BigDecimal.java:4529)"
    "java.base/java.math.BigDecimal.needIncrement(BigDecimal.java:4585)"
    "java.base/java.math.BigDecimal.divideAndRound(BigDecimal.java:4493)"
    "java.base/java.math.BigDecimal.setScale(BigDecimal.java:2799)"
    "java.base/java.math.BigDecimal.setScale(BigDecimal.java:2732)"
    "io.prestosql.spi.type.Decimals.encodeScaledValue(Decimals.java:172)"
    "io.prestosql.spi.type.Decimals.encodeScaledValue(Decimals.java:166)"
    "datomic.presto$create_connector$reify$reify$reify$reify__2435.getSlice(presto.clj:348)"

plexus14:12:08

could this be a bug in the connector?

ghadi16:12:41

@plexus I seem to recall the latest release notes having something about that

Michael Stokley17:12:03

are there diagramming techniques or approaches that are more suited to datomic than traditional sql rectangles - "an entity relationship diagram"?

Michael Stokley17:12:28

like drawing nodes and named edges, maybe?

Alex Miller (Clojure team)17:12:34

erds are still pretty useful as long as you keep in mind that entity "types" are a fiction of your model, not a constraint in Datomic

🙏 3
Michael Stokley17:12:00

thank you! looks like it leaves off the entity names - which, as you say, are a fiction.

Alex Miller (Clojure team)17:12:07

in any of those rectangles you have a bunch of attributes that are used together (but just keep in mind that the box doesn't really exist). the lines (attributes) are the important part

Alex Miller (Clojure team)17:12:10

I think yellow boxes there indicate uniqueness

Alex Miller (Clojure team)17:12:44

that one has a stronger sense of entity type (but really is just a shared namespace for the attrs)

Alex Miller (Clojure team)17:12:36

these are both good examples of what Datomic devs do - different variants may emphasize different aspects of the schema (type, cardinality, uniqueness, component)

Michael Stokley17:12:45

this is very helpful, i appreciate it.

Michael Stokley17:12:40

good to know that this is the diagramming style favored by other datomic developers.

Wojtek20:12:27

I have few really slow datomic queries - how could I improve them?

Lennart Buit22:12:30

The usual answer would be: do you have the order of your clauses correct

Wojtek23:12:24

thank you! but I have already tried to reorder my clauses without improvement 😞