Support nullable and non-nullable types with same name in the same template #3658
Conversation
📊 Metrics Diff Analysis ReportSummary
ℹ️ About this analysisThis automated analysis compares query planner metrics between the base branch and this PR. It categorizes changes into:
The last category in particular may indicate planner regressions that should be investigated. New QueriesCount of new queries by file:
|
| private @Nonnull final Map<Type, String> typeToNameMap; | ||
| private @Nonnull final Map<String, Type> nameToCanonicalTypeMap; |
There was a problem hiding this comment.
Is the idea here that previously, we had a one-to-one mapping between Type and String names, whereas now, there can be multiple Types that all map to the same String name (as long as the Types are equal ignoring nullability)? And that's why you need to break out the BiMap into two maps?
| @Nonnull | ||
| public Optional<Type> getTypeByName(@Nonnull final String name) { | ||
| return Optional.ofNullable(typeToNameMap.inverse().get(name)); | ||
| return Optional.ofNullable(nameToCanonicalTypeMap.get(name)); |
There was a problem hiding this comment.
I think this method is unused within the code base. Should we just get rid of it?
| */ | ||
| @Nullable | ||
| private Type findCanonicalTypeForStructure(@Nonnull final Type type) { | ||
| for (Map.Entry<Type, String> entry : typeToNameMap.entrySet()) { |
There was a problem hiding this comment.
This now introduces an Θ(n) step into creating the type repository, which would mean that creating a repository with n) types is now Θ(n2).
Did you consider an alternative design where we enforce that only the notNullable (or nullable--it doesn't matter except for certain edge cases like Type.Null) variants of each type are kept in the TypeRepository? From my reading of the type repository, we don't actually need to keep both the nullable and non-nullable variants of the type at all, as we only use it to associate a type to a Protobuf descriptor, and those are the same for the two different variants.
I think the basic shape of the solution would look something like:
- Modify the builder to store only the (non) nullable version of each type
- Wrap the access paths to the
typeToNamebi-map with logic to first transform the type to its (non) nullable variant
| headquarters Address, | ||
| branch_offices Address array, |
There was a problem hiding this comment.
If it I take it, the reason this covers the new logic is that the Address array will be an array of non-nullable Address structs, whereas the headquarters Address will be a nullable type. It might make sense to add an explicit table here where there is both an Address column and an Address NOT NULL column.
| # | ||
| # This source file is part of the FoundationDB open source project | ||
| # | ||
| # Copyright 2021-2024 Apple Inc. and the FoundationDB project authors |
There was a problem hiding this comment.
| # Copyright 2021-2024 Apple Inc. and the FoundationDB project authors | |
| # Copyright 2016-2025 Apple Inc. and the FoundationDB project authors |
| } | ||
|
|
||
| @TestTemplate | ||
| public void structTypeVariants(YamlTest.Runner runner) throws Exception { |
There was a problem hiding this comment.
FYI, I believe that since the PR was first created, we've sorted the test names in this file in order to decrease the number of conflicts at the end of the file
2 participants
Modify TypeRepository to allow registering 2 types (only different in nullability) in the same schema template.
Use Case:
If we have struct A, and array of A in the same template, A is nullable, while A in the array is non-nullable. This should be allowed.