Clojurians Log v2

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"]})

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)"

could this be a bug in the connector?

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

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

like drawing nodes and named edges, maybe?

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

for example, here's a Datomic schema Rich made for Codeq https://github.s3.amazonaws.com/downloads/Datomic/codeq/codeq.pdf

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

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

I think yellow boxes there indicate uniqueness

there is one for the mbrainz sample at https://github.com/Datomic/mbrainz-sample

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

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

this is very helpful, i appreciate it.

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

@mitesh 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).

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

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

https://github.com/Datomic/day-of-datomic/blob/master/tutorial/decomposing_a_query.clj

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