My initial implementation of the Hot Rod based dialect doesn't support storing of unordered bags, as I followed the example from the Cassandra dialect which stated in a comment that it is not possible to persist such objects in a key/value store as there is lack of a key definition.
suggested that this could actually be done by adding a surrogate UUID to the row key: https://github.com/hibernate/hibernate-ogm/pull/766#issuecomment-246623915
I think that could work, and in addition if we were to support embedding collections - like storing all entries of the Bag in the same row key - this should also not be a problem.
I actually think that Bags should be stored as an embedded collection by default, and possibly as only mapping option, so to avoid the UUID overhead.
Why is UUID an overhead? Not the generation of it, right? Is that the load of all rows? Isn't it the same problem for Set?
Why is UUID an overhead? Not the generation of it, right?
I was thinking about the generation indeed: it needs entropy.
Is that the load of all rows?
Sorry I didn't understand this question.
Isn't it the same problem for Set?
In a set, the tuple representing all columns represents the primary key as it's unique.
But I think the more important thought is that if you have a Bag, ORM will need to load all elements anyway so there's no benefit at all in mapping such elements on separate "rows". So we could make it mandatory to store such a collection as an embedded collection (like I think a user would store a bag in Protobuf..) and not give the option of separation.
right but it feels weird that half of my collections are done in fashion X and the other half imposes fashion Y.