This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-05-10
Channels
- # announcements (4)
- # beginners (111)
- # boot (34)
- # cider (67)
- # cljdoc (10)
- # clojure (90)
- # clojure-dev (37)
- # clojure-europe (3)
- # clojure-gamedev (3)
- # clojure-italy (18)
- # clojure-losangeles (2)
- # clojure-nl (27)
- # clojure-spec (24)
- # clojure-uk (59)
- # clojurescript (41)
- # cursive (32)
- # datomic (31)
- # emacs (21)
- # figwheel (1)
- # figwheel-main (2)
- # fulcro (43)
- # graalvm (6)
- # graphql (3)
- # jobs-discuss (3)
- # kaocha (1)
- # nyc (1)
- # off-topic (22)
- # pathom (10)
- # pedestal (11)
- # re-frame (9)
- # reitit (17)
- # shadow-cljs (15)
- # spacemacs (13)
- # sql (6)
- # testing (5)
- # tools-deps (3)
- # vim (13)
- # yada (1)
i see. what's the reasoning for returning #:db{:id nil}
vs {}
or just nil
for no matching result?
makes it harder to do nil punning, although that's easy enough to add a helper function for
@(d/transact (user/conn) [[:db/add :application/address :db/fulltext true]])
Execution error (Exceptions$IllegalArgumentExceptionInfo) at datomic.error/deserialize-exception (error.clj:124).
:db.error/invalid-alter-attribute Error: {:db/error :db.error/unsupported-alter-schema, :attribute :db/fulltext, :from :disabled, :to true}
So I guess the docs are right about “You cannot alter :db/valueType or :db/fulltext”…? Initially I hopefully thought that maybe this means that you can’t remove the :db/fulltext
after you have set it to true, but I guess hopes were slightly too high.
What would be the best way to continue? Create new entity attribute :application/address2
with :db/fulltext true
and migrate entities to use that? Any other suggestions? Thanks! 🙂How about renaming :application/address
to :application/addressOld
and then copy the old to the new attribute that has :db/fulltext true
?
is there a JVM or Linux setting that might cause datomic client to not properly read UTF-8 characters (e.g. é) from the database?
I can properly read in an ion, also on localhost when connecting to the bastion, but we run a Beanstalk application which uses datomic client api and that one consistently reads UTF8 characters wrongly
the weird thing is, the data comes in on the same instance through an API call, gets properly written to datomic (we can validate that at an ion or local dev), but when reading it back on the same instance, it doesn't have the proper encoding
what's a good schema for a message body with versions in multiple languages? I was thinking something like:
:message/en
:message/zh
:message/fr
...
but I'd have to modify the schema every time I add a new language. curious if there are any other options.Do Ident and DB.uqiue/identity always go together? Like, can you use ident when your declaring it unique? It would seem so from the docs, but I don't understand what the relationship is then
At ok, so ident is for the attribute, which is an entity itself, but to say this attribute plus a value is a pointer to an entity you have to declare it unique. Right?
And unsure value, means there can only be one such pointer to the entity
:db/ident
can be added to any entity, not just attribute. And it is used to be able to refer to the entity with a keyword.
Ok, what makes an attribute an attribute?
:db.install/attribute is a special bootstrapped attribute created in the first three transactions of a fresh db
you used to have to assert :db.install/attribute explicitly when adding an attribute but it's implicit now
All attributes are entities right? So we must have to add information to make it an attribute.
This assuming I understand the idea of an entity, which I take to be, the set of facts/datoms connected to this entity id.
Ok right, so if you don't use ident then you can only refer to it by it's id
So if you give it unique identity but not an ident then you could use the entity id plus a value to look up?
Like saying :name is a unique identity, but without ident, would mean I would have to use the entity id plus the name. [5677 "Drew"]