Composite index structures about mobstr HOT 3 CLOSED

After further thought on this, I'm not sure that it's worth the effort to do this. The main issue is that there's no (good) way to maintain a Set as a key for a record. This could, however, utilize something like a red-black tree or a splay tree with a custom comparator, but then the comparator has to be kicked up to the user to be defined which is a bit awkward.

Thinking about this from a front-end store implementation, would this even be useful? I can see the constraint checks being useful during creation of objects from a form. However, most objects will come from an external API which should already have a primary key representation.

from mobstr.

I'm changing the description of this to scope it to complex index structures. If I can solve index values with a complex shape then I can possibly leverage that solution for primary keys as well since they live in the same space.

from mobstr.

"Inspiration" struck. We can use the popular object-hash to conditionally hash non-primitive values. This is fairly slow, so indexes on lists or objects are not trivial

from mobstr.