Clojurians Log v2

the case I'm planning, I don't think I would need to really query inside them... just load this (seldom changing) data once and it is cached in my application's memory... so I'm tempted to just use bytes to serialize the long id numbers

also the lists are mostly short (at most tens, definitely not hundreds of entries) so the 4k size limit of single value isn't close

I think the perspective is still valid. @favila and I had some deep conversations somewhere in this channel about the fundamental difficulties in managing "human-friendly" sequential identifiers in Datomic. I think indices fall into that category as well. If your application can assign the indices safely (no possibility of race conditions from competing transactions) then you are in a happy place. If not, you will either need a transaction function to assign the next available index or use CAS to optimistically assign the likely next index. It's really not too hard for the basics. This assumes you use a position/index attribute to order your list.

Thing I have done before is use bigint bigdec for variable-precision sort

It gets harder if you want to use human-friendly positions (e.g. 10, 20, 30...) versus plain numbers. It gets harder if the positions are scoped to some parent entity (think order lines scoped to an order). It gets harder if you want a transaction function to be generally useful for create or update.

bigint bigdec means insertion between two items can bump precision instead of renumber a bunch of items

it was much more complicated though

not confident I could reimplement that blind right now

That's a neat trick!

This lib does the 'bisection' / precision bump trick also, but with variable length strings https://github.com/Cumulo/bisection-key.cljs

It would be great to have some documentation on what is considered idiomatic in this context. I have an entity that has two references and an order number, but this structure doesn't feel idiomatic. I would have thought ordering would be quite common.

I have spent a lot of time in the past couple of months working on good practices and idioms for managing "order numbers" and dependent "order lines". It has not been easy and our current "best practice" might not be the same answer you get from others or even from my past and future selves. Order Numbers are identified by the :db.unique/identity attribute :order/number and assigned by a transaction function that uses an auxiliary entity to track the next available number in a series (orders can be numbered in series, e.g. the "10000 series" and the "20000 series"). Order numbers are longs. Order Lines are associated with orders two ways: one is via an isComponent attribute in the parent order and the other is via a tuple of [:order/number, :order.line/number]. The line numbers (multiples of 10) are assigned via a transaction function that knows how to scope the numbers to the parent order. The unique tuple is assigned by a separate tx-fn after the order and line numbers have been assigned. Coordinating these tx-fns for new and existing orders has been very difficult and has forced me to build out a whole infrastructure of tx-fns that allow for nicer composition than "plain" tx-fns. The net of it all is that we have replicated the common business model of order and lines with "human-friendly" numbering. I could go into much more detail on the pro and cons of each of the design decisions needed to reach this point but this post is getting too long. I'm happy to provide more context if you have a specific question.

that bisection-key looks neat, you only have to change 1 attribute of 1 entity when changing the position inside a list