Introduce Flat Collection Types#259
Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #259 +/- ##
============================================
- Coverage 80.48% 80.46% -0.02%
- Complexity 1297 1330 +33
============================================
Files 230 231 +1
Lines 5948 6000 +52
Branches 536 537 +1
============================================
+ Hits 4787 4828 +41
- Misses 797 805 +8
- Partials 364 367 +3
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
LGTM |
suresh-prakash
left a comment
There was a problem hiding this comment.
Partially reviewed (till JsonIdentifierExpression.java)
|
|
||
| private AliasedIdentifierExpression(final String name, final String contextAlias) { | ||
| super(name); | ||
| super(name, null); |
There was a problem hiding this comment.
This change is not required?
| this.arrayType = arrayType; | ||
| // Package-private: used internally by factory methods | ||
| ArrayIdentifierExpression(String name, FlatCollectionDataType arrayElementType) { | ||
| super(name, null); |
There was a problem hiding this comment.
Can simply invoke the base super(name); constructor?
| return of(name, PostgresDataType.TIMESTAMP); | ||
| } | ||
|
|
||
| public static ArrayIdentifierExpression ofTimestampsTz(final String name) { |
There was a problem hiding this comment.
This class is supposed to be agnostic of the underlying database. Using Postgres specific-types here breaks the abstraction.
I'm especially concerned since we have a ofTimestamp() and ofTimestampsTz().
This might create a tight coupling.
If necessary, we should have abstracted type-definitions for document-store, which can later map to the database type-specific types during the query translation.
If we want to make it ideal, we should keep PostgresDataType at the module/library level.
There was a problem hiding this comment.
@suresh-prakash Sure, added generic types to remove this coupling. We've specific extractors for PG now that do this mapping.
| return of(name, PostgresDataType.DATE); | ||
| } | ||
|
|
||
| public static ArrayIdentifierExpression ofUuids(final String name) { |
There was a problem hiding this comment.
Do we need to create a public method for every Postgres type here? I'd start with minimal types what is required (and common across different database types) and live with it and start adding more on a need basis.
There was a problem hiding this comment.
Removed unnecessary type like UUID but kept TIMESTAMPZ and DATE (if feel we might use these types more than UUID, so I don't want to make a new code change to introduce these types later).
| return getArrayElementType().map(this::toPostgresArrayType); | ||
| } | ||
|
|
||
| private String toPostgresArrayType(FlatCollectionDataType type) { |
There was a problem hiding this comment.
Having the name "toPostgres..." in a generic class breaks abstraction though it is private. If it's possible, I'd avoid it.
There was a problem hiding this comment.
Added generic types.
| public static IdentifierExpression of(final String name) { | ||
| Preconditions.checkArgument(name != null && !name.isBlank(), "name is null or blank"); | ||
| return new IdentifierExpression(name); | ||
| return new IdentifierExpression(name, null); |
There was a problem hiding this comment.
Instead of having to deal with nulls, it'd be better to introduce a "safe" enum (like how proto. does).
There was a problem hiding this comment.
Introduced a UNSPECIFIED type here.
|
|
||
| String name; | ||
| // Type information of this identifier for flat collections, optional | ||
| FlatCollectionDataType flatCollectionDataType; |
There was a problem hiding this comment.
If it's nullable, better to annotate it as @Nullable so that we get compilation issues.
There was a problem hiding this comment.
This is no longer a part of the public API so don't think this is needed anymore.
| } | ||
|
|
||
| public static IdentifierExpression ofTimestamp(final String name) { | ||
| return of(name, PostgresDataType.TIMESTAMP); |
| protected JsonIdentifierExpression( | ||
| String name, String columnName, List<String> jsonPath, JsonFieldType fieldType) { | ||
| super(name); | ||
| super(name, null); |
There was a problem hiding this comment.
Can we avoiding these changes.
| FLOAT, | ||
| DOUBLE, | ||
| BOOLEAN, | ||
| TIMESTAMPTZ, |
There was a problem hiding this comment.
Can you add a comment on this enum? It is not evident what the TZ suffix represents.
| return of(name, DataType.BOOLEAN); | ||
| } | ||
|
|
||
| public static IdentifierExpression ofTimestampTz(final String name) { |
There was a problem hiding this comment.
Either a documentation comment will be helpful, or would be better to drop the Tz suffix.
There was a problem hiding this comment.
Added doc for this.
Description
This PR introduces a database-agnostic type system that can be used to provide compile time type metadata to query parsers, which can use this info to generate type-aware optimisations.
Testing
[x] Added UTs
[x] Tested this in a live env
Checklist: