Preference for approaches to ordered lists in Datomic?

Background: In Datomic, cardinality/many relationships are sets. Therefore any inherent ordering in the original collection is by default lost upon storage. To preserve sequential information, one must manually implement a linked list or a position attribute, or serialize the list and store that.

Question: Fellow Datomic users: how are you finding each of these options? Are there some that feel particularly elegant or clunky in your use case? Have you perhaps switched from one approach to another, or do you plan to? I’ve been tracking position in other attributes and I feel rather ambivalent about the need to manually maintain that attribute.

(Aside: First-class ordered lists are a feature request from 2012, per Stuart Halloway:

The top-level decision with lists is “Do you want to query inside them?” If the answer is yes, then you should model a linked list or a positional list in Datomic. If you do not need to query inside lists, then you should request that we add support for lists as a first-class type. :slight_smile: (We are already considering this.)

I’ve upvoted the “Ordered multivalues” feature request in and agree that first-class support would be stellar.)

The first step is to consider serialization, for which point you should answer 2 questions:

  • do I want to query the list elements?
  • do I want to benefit from the write semantics (granular updates, upserts etc.) of Datomic to update the content of the list?

If the answer is no for both questions, then you can serialize - for choosing the serialization format, you should consider performance, readability, and availability on the Transactor. For instance, EDN is readable, slow, and available on the Transactor. JSON is readable, fast, and not available in the Transactor unless you’ve added it to the Transactor classpath.

When not serializing, I’ve been using ‘Array Lists’, i.e a to-many, component relationship to Cell entities that have an ‘index’ attribute and a ‘content’ attribute: Datofu provides an implementation of that. I find it more pleasant to query against than a Linked List, but the downside is that some atomic updates are not as easy to write, e.g inserting an element in the middle of the list.

1 Like

I’ve had good success with although it suits/assumes the peer API since my code walks the links to read. I don’t think it will work well using the client/cloud API. I’ve yet to try that.