Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move null interpretation to record type meta-data #677

Open
alecgrieser opened this issue Jul 31, 2019 · 0 comments
Open

Move null interpretation to record type meta-data #677

alecgrieser opened this issue Jul 31, 2019 · 0 comments
Labels
enhancement New feature or request

Comments

@alecgrieser
Copy link
Contributor

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.

@alecgrieser alecgrieser added the enhancement New feature or request label Jul 31, 2019
alecgrieser added a commit to alecgrieser/fdb-record-layer that referenced this issue Aug 2, 2019
… 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant