This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-05-19
Channels
- # announcements (3)
- # beginners (29)
- # biff (10)
- # calva (33)
- # cider (1)
- # clara (8)
- # clerk (10)
- # clj-kondo (6)
- # cljs-dev (5)
- # clojure (40)
- # clojure-dev (3)
- # clojure-europe (43)
- # clojure-gamedev (1)
- # clojure-nl (1)
- # clojure-norway (19)
- # clojure-uk (2)
- # clr (3)
- # cursive (12)
- # datomic (4)
- # devcards (3)
- # gratitude (3)
- # honeysql (13)
- # hoplon (25)
- # humbleui (3)
- # hyperfiddle (38)
- # malli (26)
- # pathom (38)
- # practicalli (2)
- # rdf (6)
- # reagent (8)
- # shadow-cljs (13)
- # xtdb (1)
I see that the Cloud docs state a limit of 1024 digit precision for BigDecimals, while the on-prem docs do not. Does that mean on-prem supports true arbitrary precision for BigDecimals?
I think that the answer is the same as in strings: strings in cloud are explicitly limited in 4096 chars long in cloud, in on-prem, there is no limitation inside datomic code, but it may break in some other part of your system (JVM, dynamodb, SQL command size, etc..)
I’d also like to better understand the behavior alluded to here when scales don’t match: > • Consistent results in query depend on the scale matching for all BigDecimal comparisons. You are strongly encouraged to use a consistent scale per attribute. If I will never query by this value, do I need to worry about mismatched scales? (I’m considering using a BigDecimal attribute to represent a position in an ordering, so I only care about the relative magnitude of the values.)
I am experiencing a discrepancy between dev-local and client-cloud when querying Datomic passing :timeout nil
. In dev-local, the query works as expected, but in Datomic Cloud, it fails with a Datomic Client Exception
. I’m using dev-local 1.0.243
and client-cloud 1.0.123
.