This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-01-16
Channels
- # aleph (2)
- # announcements (1)
- # aws (2)
- # babashka (5)
- # beginners (122)
- # boot-dev (1)
- # cider (3)
- # clara (7)
- # cljdoc (11)
- # clojure (161)
- # clojure-dev (45)
- # clojure-europe (8)
- # clojure-france (1)
- # clojure-india (1)
- # clojure-italy (3)
- # clojure-nl (11)
- # clojure-uk (34)
- # clojurebridge (2)
- # clojurescript (13)
- # cryogen (10)
- # cursive (13)
- # datomic (25)
- # emacs (8)
- # fulcro (76)
- # graalvm (2)
- # jackdaw (5)
- # jobs-discuss (2)
- # juxt (13)
- # off-topic (13)
- # pathom (5)
- # pedestal (7)
- # quil (2)
- # reitit (9)
- # remote-jobs (4)
- # schema (1)
- # shadow-cljs (33)
- # spacemacs (8)
- # sql (9)
- # vim (2)
- # vrac (2)
I have a schema attribute with db.type/float
. When I try to transact the value 3.14, it actually transacts 3.140000104904175. What is going on?
The problem can be in some serialization, where the float converts to a bit representation (perhaps in fressian if that is used) and then back. The answer is not wrong per se (because floats are imprecise) but I understand you find it surprising. If you really want to use 3.14 as 3.14, use BigDecimal and 3.14M or try if Double is serialized in a more precise way. I’m not sure it will work either but worth a try.
(:db.type/decimal and :db.type/double)
(I have no insight in the Datomic code base)
It doesn't lose precision with doubles. Unfortunately, changing float to double is not a supported schema alteration.
This is a common issue with floating point. Unless you're doing something where exact precision is critical (typically currency or some scientific work) I'd say the standard solution is to round it at the point of display -- as you can see from the example, the difference is so tiny that you could round to anywhere from 2-8 digits and get the right answer. As @UQY3M3F6D points out, using BigDecimal avoids the problem entirely, at the cost of being a) computationally much more expensive/slow, and b) annoying to work with (although less so in Clojure than in Java). Here's a well-known & useful article on the topic: https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
I noticed the other day that datomic.client.api/q
doesn’t support query on a collection of facts:
(d/q '[:find ?name
:where [_ :person/name ?name]]
[[1 :person/name "Tim" 42]
[2 :person/name "Jasmin" 42]])
Execution error (ExceptionInfo) at datomic.client.api.impl/incorrect (impl.clj:42).
Query args must include a database
I remember this being supported in on-prem: https://docs.datomic.com/on-prem/query.html#database-of-facts
Is there any way/talk to support this?We are using a :db/ident as an enum. in Datomic Cloud. When I do a :find (pull ?e [*]) I get the :db/id but not the actual keyword. What is the correct way to implement enums in Datomic in the year 2020?
https://docs.datomic.com/cloud/schema/schema-modeling.html Is the enum a ref like above?
Yes, exactly. The problem is, how to return :country/JP from a query rather than just use it in a where clause.
Is there any disadvange in use a keyword type instead? It simplifies things for sure.
I cant say for sure what the disadvantages would be, however I think modeling things that way sounds great if it meets your applications needs.
@U050VTWMB what’s wrong with querying for :db/ident specifically? using asterisk is considered to be anti-pattern for production queries. I agree that keywords are more convenient in some cases, but idented entities have a few pros: a) they’re entities thus extensible with additional data b) misspellings are validated on-write by db itself
Using a keyword for enums: 1) enum set is “open” (you don’t need to transact ahead of time to create another enum) 2) you get a keyword value in pulls
Using a ref for enums: 1) enum set is “closed” (you must transact ahead of time) 2) slightly more efficient storage 3) indexing by value is automatic 4) you can annotate enum entities with additional assertions (they are “just” entities after all. For e.g. you can document/enforce attribute range and and enum set membership with more attributes) 5) pull gives you {:db/ident :keyword-value}