You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment, the null interpretation for, for example, determining whether a field in a proto3 field is nullable or not (or if one should take the default value) or for determining if the null is a "real" value that should be considered for uniqueness checks is all in the key expression. This means that (1) users need to make sure that they are consistent about using the same null interpretation everywhere and (2) they have to be careful about setting the right null interpretation when evaluating a sort, etc. It seems like the semantics of what the field means should be included instead in meta-data on the record type, and then all callers can just use a vanilla "field" expression, and the record type meta-data should be rendezvoused with the index maintainer in a way where it extracts the right value.
There will need to be some kind of transition plan for moving old indexes to use this new format.
The text was updated successfully, but these errors were encountered:
… check for fields
This removes the `NullStandIn` checking in the `.equals` method from the `FieldKeyExpression`. It also removes it from that fields hash code methods, and it removes the `equivalentForSort` method from all key expressions, as it was only used to check for the `NullStandIn` anyway. It references FoundationDB#677 in a few places, which is the issue to move this into meta-data that is stored at the `RecordType` level, as having mixed values for different indexes does not really make sense.
At the moment, the null interpretation for, for example, determining whether a field in a proto3 field is nullable or not (or if one should take the default value) or for determining if the null is a "real" value that should be considered for uniqueness checks is all in the key expression. This means that (1) users need to make sure that they are consistent about using the same null interpretation everywhere and (2) they have to be careful about setting the right null interpretation when evaluating a sort, etc. It seems like the semantics of what the field means should be included instead in meta-data on the record type, and then all callers can just use a vanilla "field" expression, and the record type meta-data should be rendezvoused with the index maintainer in a way where it extracts the right value.
There will need to be some kind of transition plan for moving old indexes to use this new format.
The text was updated successfully, but these errors were encountered: