Advice for storing ranges?

Datomic Cloud
1

I need to store ranges of longs, including an inclusivity flag for the top and bottom of the range.

I’m currently considering using either a many-cardinality ref to a separate range entity, or a heterogenous tuple, but I’m not sure about the tradeoffs involved.

Since a range doesn’t have meaningful uniqueness semantics, I suspect I’ll need to do a compare and swap where, upon receiving an updated set of ranges, I create a retraction for any extant ranges in the db not present in the new set, and assertions for ranges not present in the db, and this is true no matter how I represent this (so far as I can tell).

What I’m unclear on is whether asserting and retracting an entity with 5 attributes (min, max, min-inclusive?, max-inclusive?, type) is worse on the db than asserting and retracting a tuple with 5 fields.

I’m also too new to Datomic to know whether the ergonomics around querying will be nicer with a range entity than it will be with a tuple, or if they’re about equal.

I’d love to hear the thoughts of others on their experience with tuples vs entities.

All the best,
Evan

2

@evangg if you decide you want to go with storing an entity with 5 attributes, you can create as many composite tuple indexes as you need “on top” of the existing data using :db/tupleAttrs. If you find you need a different view into the data you can add a new tuple schema which references the existing attr names, then run a pass over the datoms like day-of-datomic/composites.clj at master · Datomic/day-of-datomic · GitHub to ensure the new index is established

3

Hey @bhurlow, thanks for those tips :slight_smile: I’ve decided to use a range entity until I hit perf issues, which I honestly suspect I won’t ever, given how these ranges are used and how infrequently they change.

1 Like