Clojurians Log v2

Here's the repo https://github.com/panterarocks49/datascript-firebase

I'm wondering about the possibility of implementing a first class sequential list type in datascript. I've read https://github.com/tonsky/datascript/wiki/Tips-&-tricks#preserving-order and understand there are ways around it, but if I wanted to fork datascript and implement a real list type, definable in a schema, is there a fundamental reason that is either hard or a bad idea? Or is the lack of lists more to mirror the featureset of datomic?

what’s the upside of adding it to data script over querying, then sorting? or adding a vec or list?

mainly because an attribute is logically sequential it would be nice to be able to lean on the schema to manage this rather than have to manage it myself in code (either by sorting or manually appending to a list)

I'm sure this alone doesn't justify maintaining a separate version of DS, just kind of curious at this point if there are major limitations

I would personally love something like this. Particularly updating orders in a ref-many list is quite annoying. But I don't think I would switch from ds to a fork, would have to be a wrapper

@jjttjj Have you looked at the new Datomic tuple support? Seems like that's more or less what you want, with some tx-functions to manage things like "append".

Note: tuple is much more generally useful, as it lets you do things like compound indexes.

Tuples seem interesting and I will have to more thoroughly research them, but from an initial look it seems they can contain at most 8 values which isn't suitable for my use case

Datomic and datascript are fundamentally a relational set based model, which just works more elegantly if you normalize (break your list apart, store as separate rows/datoms). If you leave your collection inline, you won't get as nice indices for certain kinds of queries

https://www.postgresql.org/docs/10/gin-intro.html might be useful reading for adding an index that works for composite types