Hey, thank you for exploring this with me.
What I expected, and what I would suggest, is that refs for the currently indexed doc (the “identity ref”, I called it) would be automatically excluded In uniqueness constraints. If the values for a given doc included the ref for the same doc, that ref is not included in the uniqueness test. All other terms and values (including other refs) are included, per the current rules.
Why?
- The identity ref will always make a uniqueness constraint a no-op. If you include an identity ref, you might as well not make the index unique. Every indexed doc in the collection will be unique from an identity perspective, by definition.
- From my initial perspective, excluding the identity ref from uniqueness was what the default “values” behavior (indexing the ref as the values) sets as precedent. That’s what happens when you don’t set a
values. It’s surprising to me that spelling “my values should be a ref to the indexed doc” as a default gets you one uniqueness behavior, while spelling it as afield: [‘ref’]or a binding gets you another. I expected the default behavior to be precisely equivalent to the other spellings, and that is my suggestion. - It would be useful to have this behavior. It would mean, for instance, that I could make a uniqueness constraint/index that only applies to a subset of docs, by using a binding in values that only includes the identity doc if it should participate in the uniqueness constraint (by whatever logic). I could use this now. (I can accomplish it in other ways, but they waste storage and make the index less useful for other needs.) It would also mean that a unique index could be sorted (assuming that the sorting value is also a desired uniqueness element), and thus used more flexibly than merely as a uniqueness constraint. I could use this now also. (I can accomplish this by creating an additional index, of course.)
I hope that explanation is clearer and more compelling than my first attempt!
Thanks again,
Gary