Fork me on GitHub

@stuarthalloway: I know this is an old answer, but what did you mean by "For attributes that are marked :db/index true, it would be possible for the query engine to use predicates to avoid streaming all values of an attribute. That is planned, but not yet implemented."? Isn't that what the index is for? From!msg/datomic/IxyFQnodrF0/in1vewXEzs8J. And here's another example where it comes up:!msg/datomic/fsowOBbhvXU/dWHpj7JiDdQJ


Can anyone explain the following? In it says

:vaet contains datoms for attributes of :db.type/ref
:vaet is the reverse index
It looks like a mistake when reading it since there's one line for each index but two lines for :vaet, but it might mean that :vaet is the reverse of :eavt.


Has anyone solved the datomic (recent) with aleph problems without excluding hornetq server and depending on hornet 2.4.8?!msg/datomic/pZombLbp-tQ/pyU37oAnAgAJ


@timgilbert the id of the database value is the uri afaict, unless you're using the mem db (:id (d/db conn))


@danielstockton yep, just confirmed, you do get the uri out if you use :id, which gives you a java.util.URI. str on that value to get back to the value you gave to d/connect


(keys some-db) reveals a bunch of interesting things: (:id :memidx :indexing :mid-index :index :history :memlog :basisT :nextT :indexBasisT :elements :keys :ids :index-root-id :index-rev :asOfT :sinceT :raw :filt)


Oh, interesting. Thanks guys!


Do you see anything wrong with the following transaction? I'm getting a IllegalArgumentExceptionInfo :db.error/not-an-entity Unable to resolve entity: :bot.log.msg.kind/outgoing in datom [#db/id[ -1] :bot.log.msg/kind :bot.log.msg.kind/outgoing] when using it with datomic.api/with


Even more strangely, it seems to work if I wait a few minutes.


@val_waeselynck: is :bot.log.msg/kind valuetype ref or keyword? if ref, have you previously transacted [:db/add <tempid> :db/ident :bot.log.msg.kind/outgoing] ?


it's ref, and yes I have transacted it


Alright, I have an offbeat question. When you pass d/tx-range an #inst, does it resolve that to a t in order to pull from the log? If so, how is that resolution done?


@potetm: You could have several transactions processed within the same second (inst), but different t.


"Datomic's own t time value exactly orders transactions in monotonically ascending order, with each transaction receiving its own t value."


Hey @jaret! I see what you mean, multiple t values could be applicable for a given #inst. I was wondering how that resolution happened. For example, does it look in the index? (Yeah this in reference to the issue I just updated 😄 )


I thought someone here might just know offhand, and that would explain it.


In hindsight, it was a real shot in the dark.


s/safe/going to work/


They should if you follow the steps as written


Heya folks, I am having some trouble wrapping my head around modeling data in Datomic. Let's say I have Company which has 0 or many Applications. I would like to ensure that while I only have a few types of Applications named: "A", "B", and "C", that a Company cannot have more than one "A" application. I imagine something like:

name: string, cardinality: one, unique: value
applications: ref, cardinality: many, unique: ???

_company: company, cardinality: one
name: string, cardinality: one, unique: ???


An Application will have additional attributes beyond just a name and a reference back to company.


Reasoning out loud: I can't set unique on an attribute which has a cardinality of many, so would I use unique: identity on an application?


Should I use an enum for the name, since there is a limited, known set of application names?