This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-02-27
Channels
- # announcements (8)
- # architecture (3)
- # aws (18)
- # beginners (96)
- # bristol-clojurians (3)
- # calva (15)
- # cider (7)
- # clj-kondo (8)
- # clojure (135)
- # clojure-denmark (1)
- # clojure-dev (14)
- # clojure-europe (37)
- # clojure-italy (9)
- # clojure-nl (14)
- # clojure-sanfrancisco (1)
- # clojure-spec (1)
- # clojure-uk (54)
- # clojurescript (27)
- # core-async (243)
- # cursive (28)
- # data-science (6)
- # datomic (33)
- # fulcro (25)
- # graalvm (24)
- # hoplon (2)
- # instaparse (12)
- # jackdaw (1)
- # java (21)
- # juxt (12)
- # meander (10)
- # nyc (4)
- # off-topic (6)
- # om (3)
- # pathom (17)
- # perun (1)
- # re-frame (29)
- # reitit (4)
- # rum (3)
- # shadow-cljs (119)
- # spacemacs (31)
- # xtdb (14)
Has anyone seen this?
clojure.lang.ExceptionInfo: entity, attribute, and new-value must be specified
at datomic.client.api.async$ares.invokeStatic(async.clj:58)
at datomic.client.api.async$ares.invoke(async.clj:54)
at datomic.client.api.sync$eval2142$fn__2147.invoke(sync.clj:84)
at datomic.client.api.protocols$fn__14323$G__14277__14330.invoke(protocols.clj:72)
at datomic.client.api$transact.invokeStatic(api.clj:181)
at datomic.client.api$transact.invoke(api.clj:164)
[{:db/id 1,
:foo/apple 0N,
:foo/processed-time #inst "2020-02-27T02:00:35.561-00:00"}
{:db/id 2,
:foo/apple 0N,
:foo/processed-time #inst "2020-02-27T02:00:35.562-00:00"}
[:db/cas 3 :user/speaker 0N 100N]
[:db/cas 4 :user/speaker 85N 100N]
[:db/cas 5 :bar/running? true false]
{:db/id 5,
:bar/end-time #inst "2020-02-27T02:00:35.569-00:00",
:bar/result? false}]
What version of the compute stack are you running? CAS with a boolean might be problematic- I forget.
Ok if your ids are legit, then take out the boolean CAS and see if you get an error. If you do, I’ll file a report (need your compute stack versions)
You might want to upgrade your stack to latest. I feel like I’ve filed this bug before with the crew but I’ll double check
In datomic cloud 8812 we had a problem with a big transaction creating entities with multiple levels of nested maps... some children ended up on the wrong parent... the same code on newer version worked correctly. I tried looking at release notes but didn't see bug fixes related to that
Good morning @ghadi @shaun-mahood! I successfully got an complex atomic transaction working this morning! Thanks again for your help!
https://docs.datomic.com/on-prem/pull.html#as-example This example is wrong Should be
[(:artist/name :as "Band Name")]
bump it is frustrating for newcomers to fail on running doc examples I feel uncomfortable recommending something that the thin documentation doesn't work
apologies for the cross post, but i was wondering if anyone has an answer to this forum post regarding a single transaction of two facts about the same entity resolved by a composite tuple? thanks! https://forum.datomic.com/t/conflict-when-transacting-non-unique-values-for-entities-resolved-by-composite-tuples/1367
That seems like the expected behaviour to me. You're asserting two values for a single-cardinality attribute of one entity, within one transaction. There isn't a concept of "newer" within one transaction, so its a conflict.
If you split this into two transactions, then of course there would be no problem as you assert abc123
and then abc789