This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-12-02
Channels
- # adventofcode (76)
- # announcements (1)
- # asami (1)
- # babashka (31)
- # beginners (302)
- # calva (3)
- # cider (1)
- # clj-kondo (1)
- # cljdoc (1)
- # cljfx (63)
- # cljsjs (2)
- # clojure (36)
- # clojure-europe (29)
- # clojure-gamedev (2)
- # clojure-nl (5)
- # clojure-sanfrancisco (2)
- # clojure-spec (2)
- # clojure-uk (71)
- # clojurescript (19)
- # conjure (21)
- # core-async (10)
- # core-matrix (1)
- # cryogen (4)
- # cursive (12)
- # datomic (22)
- # emacs (4)
- # events (1)
- # figwheel-main (7)
- # fulcro (9)
- # graalvm (1)
- # jobs (1)
- # kaocha (17)
- # lambdaisland (1)
- # meander (7)
- # mount (2)
- # nrepl (12)
- # off-topic (35)
- # re-frame (15)
- # reagent (17)
- # remote-jobs (1)
- # reveal (41)
- # shadow-cljs (13)
- # spacemacs (2)
- # tools-deps (24)
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?@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).
Thank you so much pithyless, this was of great help! I'm going to try these out and see what works for me. 🙂
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)"
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.
The usual answer would be: do you have the order of your clauses correct