-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Introduce Object Type handling in SQL [HZ-2312] #24356
Introduce Object Type handling in SQL [HZ-2312] #24356
Conversation
run-lab-run |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving.
@Fly-Style @k-jamroz Please check the getAllDataConnectionNameWithTypes
method as it returns row as Object[] inside which there is an ArrrayList, with type JSON.
No idea if that is correct or not.
hazelcast-sql/src/main/java/com/hazelcast/sql/impl/schema/view/View.java
Outdated
Show resolved
Hide resolved
public ViewTable(String schemaName, String viewName, String viewQuery, TableStatistics statistics) { | ||
super(schemaName, viewName, null, statistics); | ||
public ViewTable(String schemaName, String viewName, String viewQuery, TableStatistics statistics, boolean streaming) { | ||
super(schemaName, viewName, null, statistics, "View", streaming); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall, I am coming to the conclusion we can avoid defining 'streaming' view here and do it later based on OptUtils.isUnbounded(viewRel)
in initFields
method. WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So basically always pass e.g. false
and set "real" value in initFields? I'm not that familiar with SQL yet, but if initFields is mandatory, then it makes sense
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
.getAllDataConnectionEntries(dataConnectionService, dataConnectionCatalog.getDataConnectionStorage()) | ||
.stream() | ||
.map(DataConnectionCatalogEntry::name); | ||
.getAllDataConnectionNameWithTypes(dataConnectionService) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You changed SHOW DATA CONNECTIONS
behavior, is it intended?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. Correct me if I'm wrong, but semantics will be the same - all the same connections will be shown. The only difference is that for SHOW DATA CONNECTIONS
we add additional column to provide user an information about supported object types. Idea is from this message: https://hazelcast.slack.com/archives/CJZ745RRT/p1681908716511929?thread_ts=1681849114.133969&cid=CJZ745RRT
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this causes #24415, OBJECT TYPE without CONNECTION TYPE does not make much sense.
In slack thread we dissussed adding it to SHOW RESOURCES
not to SHOW DATA CONNECTIONS
plan.getShowTarget() == ShowStatementTarget.DATACONNECTIONS | ||
? new SqlRowMetadata(asList( | ||
new SqlColumnMetadata("name", VARCHAR, false), | ||
new SqlColumnMetadata("types", JSON, false) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why JSON specifically? JSON is just a wrapper type anyway, its not like its going to provide much utility on clients or is there actually a benefit to it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It will be parseable by the JDBC client
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this causes #24415, OBJECT TYPE without CONNECTION TYPE does not make much sense
@@ -82,6 +88,7 @@ public void writeData(ObjectDataOutput out) throws IOException { | |||
} | |||
SerializationUtil.writeList(viewColumnNames, out); | |||
SerializationUtil.writeList(viewColumnTypes, out); | |||
out.writeBoolean(streaming); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need a version guard here actually? E.g. in.getVersion().isGreaterOrEqual(Versions.V5_3)
.. And it will most likely be a good idea to test this in a rolling upgrade setup just to be sure I guess (probably enough to just create some schema objects in 5.2 node and join a 5.3, verify that it has the schema objects and then drop the 5.2 member and verify that 5.3's schema is working as expected).
In a rolling upgrade these schema objects will still be transferred because they're in a regular IMap. We might need some mechanism post 5.2 -> 5.3 upgrade for handling that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually this field is no longer used if I initialize ViewTable's streaming
property based on OptUtils.isUnbounded
. I will remove it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the field was not removed from serialized form
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hazelcast-sql/src/main/java/com/hazelcast/jet/sql/impl/PlanExecutor.java
Outdated
Show resolved
Hide resolved
@@ -31,7 +31,7 @@ public final class BadTable extends Table { | |||
private final Throwable cause; | |||
|
|||
public BadTable(String schemaName, String sqlName, Throwable cause) { | |||
super(schemaName, sqlName, Collections.emptyList(), new ConstantTableStatistics(0)); | |||
super(schemaName, sqlName, Collections.emptyList(), new ConstantTableStatistics(0), "Bad", false); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
isStreaming()
should throw, we could pass original object type of bad mapping
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hazelcast-sql/src/main/java/com/hazelcast/jet/sql/impl/schema/TableResolverImpl.java
Show resolved
Hide resolved
@Nonnull | ||
@Override | ||
public Collection<String> resourceTypes() { | ||
return Collections.singleton("IMap"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should use constants so it is defined in single place
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Follow-up to #24356 Changes: - Remove View.streaming field completely, Ensure that isStreaming for view is determined - Use original object type for bad table - Update SHOW DATA CONNECTIONS description in TDD - Use constants for object type - Refactor SqlMappingContext and simplify SqlConnector.resolveAndValidateFields - Resource type is case-insensitive
Note:
This PR replaces:
with
Mongo is a new beta feature in 5.3, so it's not a separate thing for RNs, but docs must be updated accordingly.
Jira: HZ-2312
Fixes: #24302
Breaking changes (list specific methods/types/messages):
Checklist:
Team:
,Type:
,Source:
,Module:
) and Milestone setAdd to Release Notes
orNot Release Notes content
set@Nonnull/@Nullable
annotations@since
tags in Javadoc