-
Notifications
You must be signed in to change notification settings - Fork 14
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
Use ungeneralized types for flexible schema and planner #367
Conversation
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.
Looks great, just one minor change please
|
||
String getName(); | ||
//First entry is the preferred name, the remaining are for backwards compatibility | ||
List<String> getName(); |
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.
IMHO a better approach would be to have two methods:
//Name of the type
default String getName() { getNames().get(0); }
//List of names for this type (for backwards compatibility)
List<String> getNames()
Otherwise you are leaking interface specifics (i.e. that the first name in the list is the default name) to the outside and pushing the responsibility onto the user to enforce it (as you can see by the various calls in AbstractBasicType to getName().get(0))
Also, a method that returns a collection should have a plural name.
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.
Good point, got too hung up on the generic issues and forgot about interface
* type definition syntax. | ||
*/ | ||
@SneakyThrows | ||
public static RelDataType parseDatatype(String datatype) { |
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 this go into CalciteUtil?
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.
I'll actually tie it closer to the planner since it can be pretty expensive to run and the planner can hold the state we would need
Signed-off-by: Daniel Henneberger <git@danielhenneberger.com>
Signed-off-by: Daniel Henneberger <git@danielhenneberger.com>
Signed-off-by: Daniel Henneberger <git@danielhenneberger.com>
Signed-off-by: Daniel Henneberger <git@danielhenneberger.com>
Signed-off-by: Daniel Henneberger <git@danielhenneberger.com>
* Use ungeneralized types for flexible schema and planner Signed-off-by: Daniel Henneberger <git@danielhenneberger.com> * Fix generics Signed-off-by: Daniel Henneberger <git@danielhenneberger.com> * Update other file Signed-off-by: Daniel Henneberger <git@danielhenneberger.com> * Minor code changes Signed-off-by: Daniel Henneberger <git@danielhenneberger.com> * Fix equality Signed-off-by: Daniel Henneberger <git@danielhenneberger.com> --------- Signed-off-by: Daniel Henneberger <git@danielhenneberger.com>
* Use ungeneralized types for flexible schema and planner Signed-off-by: Daniel Henneberger <git@danielhenneberger.com> * Fix generics Signed-off-by: Daniel Henneberger <git@danielhenneberger.com> * Update other file Signed-off-by: Daniel Henneberger <git@danielhenneberger.com> * Minor code changes Signed-off-by: Daniel Henneberger <git@danielhenneberger.com> * Fix equality Signed-off-by: Daniel Henneberger <git@danielhenneberger.com> --------- Signed-off-by: Daniel Henneberger <git@danielhenneberger.com>
Moves away from the generalized graphql-esque type mapping to the more concrete sql types.
Some schemas are published in the registry so the flexible schema is made to be backwards compatible.
Also removes UUID type.