This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (1)
- # aws-lambda (2)
- # beginners (30)
- # boot (2)
- # cider (7)
- # cljs-dev (65)
- # clojure (130)
- # clojure-denmark (1)
- # clojure-france (1)
- # clojure-germany (2)
- # clojure-greece (1)
- # clojure-italy (19)
- # clojure-kc (2)
- # clojure-nl (12)
- # clojure-poland (1)
- # clojure-russia (11)
- # clojure-spain (1)
- # clojure-spec (20)
- # clojure-uk (176)
- # clojurescript (65)
- # css (3)
- # cursive (8)
- # datomic (26)
- # editors (94)
- # emacs (10)
- # fulcro (66)
- # graphql (5)
- # midje (1)
- # off-topic (48)
- # om-next (2)
- # overtone (1)
- # re-frame (15)
- # reagent (6)
- # reitit (10)
- # shadow-cljs (68)
- # sql (3)
It seems like I can add a datom with an attribute that isn’t described in the schema. Is that right? What does that imply? To contrast, clearly you can’t do this in a relational db (without some setup).
"I can add a datom with an attribute that isn’t described in the schema." This shouldn't be possible. Do you have an example of doing this?
I'm using datascript, I should have asked in that channel. I'll post the example tomorrow
I’m reading the docs and trying to connect the dots here: > The set of possible attributes a datom can specify is defined by a database’s schema. Which would imply, to me, you can’t add a attribute to the db without it being in the schema.
Hello Clojurians! I’ve been googling for the whole day but without any result: how can I sort datoms/entitines by their tx date in descending order? For example, to show the last 100 messages on the dashboard.
Don't use the tx date in your app code, prefer a custom attribute. You could use avet with either a negated timestamp, or with seek-datoms using an exponentially decreasing lower bound until you reach a count of 100
(taking into account there might be quite many of entities, so manual work with collections is not applicable)
@igrishaev I’m not an expert, but i believe one way is to 1. make sure to return the tx date from your query 2. call sort-by :tx-date using clojures native sort function This will work, its perf implications probably have todo with how your running datomic. Remember that part of the value proposition is that <waves hands> datomic can be treated as a value in your process. </waves hands>
Thats possible not the best way, and i might be wrong 🙂. I glanced at the docs and this might be the right place to look: https://docs.datomic.com/cloud/query/query-data-reference.html (see custom aggregates)
Hey, I'm a little confused on how Datomic caches entities in my application code. Reading this: https://docs.datomic.com/on-prem/caching.html#entity-caching ... I am wondering what
lifetime of the Entity instance is referring to. Are we talking about until the object is garbage collected? Also is this entity cache the same as the object cache: https://docs.datomic.com/on-prem/caching.html#object-cache? Thanks... (p.s. is there a preference for asking these questions in http://forum.datomic.com ?)
I think I found an answer for my questions. I found this line in the Entity javadocs (https://docs.datomic.com/on-prem/javadoc/datomic/Entity.html):
the values of its attributes are not obtained from the db until get or touch are called, after which they are cached in the entity. So I am pretty sure that we just talking about basic heap caching with a garbage collection lifetime. And if that's the case, I think that is different than the object cache. I'd love to get a confirmation on that.
The object cache is a cache of datoms: objects decoded out of a fressian block; the entity objects have their on cache of the map view of datoms
@U09R86PA4 thanks. I guess the docs @ https://docs.datomic.com/on-prem/caching.html#object-cache were confusing me because it only mentions
contains segments of index or log... I think I was missing the fact that Datomic only retrieves entities through the indexes (I think that's a little different then SQL, where an index may or may not be used, right?)
All datomic's indexes (except the fulltext index, which is a derived Lucene index) are "covering" indexes: each contains all of the data for the datoms it is indexing.
you may find this helpful to understand datomic's architecture http://tonsky.me/blog/unofficial-guide-to-datomic-internals/