Fork me on GitHub

we’re using a separate attribute, that contains the ordering as an edn string (it’s a list of #uuids, since we give each entity a GUID primary key)


@alexisvincent The other choices I know of are: an index attr (array) or an attr that points to the next item (linked list).


RE: lucene I really wish there was some tiny amount of support for custom tokenization, even if the use of it meant all performance guarantees were off.


@csm Hm, I suppose thats an approach. But you loose queryability.


@potetm I’m wondering if a generic datastructure lib for datomic would be useful or if they should be baked into each instance by hand

Matt Butler10:10:46

@devn I agree, its a great feature (fulltext) thats almost there, so even its not exposing lucene directly, some form of control would make all the difference, at least in my case 🙂


I was wondering if anyone has a good strategy to prove a datomic backup.


We run the backup job every hour, backing up to s3. When the backup finishes, we sync the s3 folder to something not AWS.


There we restore using a local transactor with dev storage


While all the different steps work perfectly fine, I would love to be able to verify that we restore exactly what we backup.


As far as I understand, running bin/datomic list-backups gives a list of t's that are based on folder names in 'backup-folder/roots'. Nothing more nothing less. Is that correct?


Ideally I am looking for a checksum for 't' at backup time, that I verify at restore time for that same 't'.


@alexisvincent if you take the [[eavt] [eavt] ..] data model - how would you model arbitrary cardinality-many order with it? this is what Datomic has to somehow do for you. it turns out that either you have to model it with extra eavt’s yourself (index attr / linked list), or you have to affect the index’s own sort, which of course messes with the indexing algorithms. guess which one Rich picked 🙂


@robert-stuttaford thanks for the answer, the choice makes sense. I’ve been thinking about this a bit and here’s what I’ve more or less arrived at: 1. Order shouldn’t be baked into the data itself (since we can have multiple orderings per list), but rather is a semantic structure on top. 2. Order isn’t only a performance booster, (i.e. give me everything, I’ll sort it myself), but also vital for expressive queries, (e.g. limiting query to first 5 items of an ordering). --- Maybe an approach would be to provide user defined indexes as named orderings that can be specified at query time?


@robert-stuttaford Do you do this via datastructures embedded into datomic?


yeah, that old chestnut … performant sort + pagination


it’s an interesting problem, with no one correct answer


seems to me that any ordering mechanism other than "whatever it is ordered in when you walk the data" requires the whole dataset to be in memory for a sort first, no matter how you do it


so, you can get insertion order in datomic, at least. Right?


@augustl Could also have a lazy index


is that a lazy index?


if so, Datomic kind of has that I suppose, since it merges the actual main datom tree periodically, not on every transaction


So for instance, given ordering based on popularity of photos, you’re more likely to view top photos, and so that would be hot in cache


I meant on demand order resolution, only when you need it


as in you maintain a subset of popular photos and sort those only?


you’d have to maintain this recency/popularity index yourself - to add things when they become recent/popular, and to remove them when they stop being either


@robert-stuttaford I’ve also run into this brain bug where I’m not so sure how to handle versioning. Say for instance you want to track file revisions, you could use datomics ‘as-of’, but… versioning is actually a ‘first class’ problem of the domain. Also, when you want to deal with data imports you might want to specify a realworld time not a datomic transaction time. How do people solve these problems in the datomic world?


you can annotate your entities with any datetime value, including transaction entities


and then write explicit queries against those


as-of and since are great for slicing and dicing what the transactor did. they are both performant implementations of d/filter, which you can make yourself


after having tried this, i’ve found that a straightforward datalog query got me there quicker 🙂


some colleagues of mine has run into something similar. They want to use datomic's time model, for tracking the position of some GPS data. But the GPS data can be delayed. So they have a delay of the maximum expected real world delay, through a queue, for inserting the data into datomic


@robert-stuttaford using d/filter instead of as-of, interesting


makes sense, as-of just does the same binary search on the sorted sets that all other operations do on the index, I suppose


@augustl I actually mean, define a global ordering on all the photos, then when you make your query where clause you do something like this

[id :user/photo ?photo] 
[(order ?photo :date)]
The order index could then be constructed lazily. You would still need to scan all the data, but you wouldnt need to store it all in memory all the time.


@robert-stuttaford In this case the time is actually needing to be set on the datom (arrow) which unfortunately aren’t first class entities in datomic (I think)


the best we have is groups of datoms as entities (transactions)


So for instance we could have different times we need to set for datoms in a transaction. For the moment I’m approaching this by adding a multi-relational arrow, implemented via an intermediary entity. Anyway, don’t want to pull you away from your work 🙂

Brendan van der Es18:10:41

Anyone know if there are any reusable specs for the datomic api? [ e.g. (s/def :db/id (s/or keyword? int? vector?)) ]


@augustl wouldn’t it make more sense to have two notions of time in the system, the time of events and the recording time of events (the later being the “datomic time”)


maybe, I wasn't aware of using d/filter instead of d/as-of as @robert-stuttaford mentioned previously