[
https://issues.apache.org/jira/browse/CALCITE-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16158182#comment-16158182
]
Christian Beikov commented on CALCITE-1913:
-------------------------------------------
[~julianhyde] I will take it further, this was just a first step into that
direction.
Yes, the functionality of {{SqlDialect.Handler}} is moved directly into
{{SqlDialect}}. Code from the {{BaseHandler}} is directly in {{SqlDialect}} and
the other handlers are inlined into their respective dialects. I didn't know
since when the {{Handler}} existed so I tried to mark things as deprecated if
any consumer of Calcite was using these classes.
I'd like to remove {{DatabaseProduct}} alltogether. In my opinion, making an
enum publicly accessible like that, has no value. Would it be so bad to replace
code like {{if (dialect.getDatabaseProduct() ==
SqlDialect.DatabaseProduct.MYSQL)}} with {{if
(!dialect.supportsNullPrecedence()}}? The implementation of the
{{MysqlDialect}} would simply return {{false}} for that capability. I don't
think this is too bad from a readability point of view and performance wise
it's probably also better. If we encapsulate these capability checks all
through methods on {{SqlDialect}} so that users can alter that behavior, what
do you think the {{DatabaseProduct}} would be useful then for? Except for
misusing it, I can't think of it being of any value.
What do you mean by "mix-in interface"? Would you propose using the standard
information schema implementation as a base implementation in {{SqlDialect}}
and then let subclasses override that? That could work too but I'm not sure if
that design is better. What is it that you would like to avoid? The additional
{{SequenceSupport}} object on which I call methods? Or the classes related to
sequence support? I guess I could put the resolving of the concrete sequence
support directly into the dialects and even inline the implementation of
{{SequenceSupportImpl}} if that is what you are getting at.
As I wrote before, this PR is far from being done, it's just a first cut.
Anyway, I hope you are beginning to like the idea and we can move this forward
:)
> Include DB version in SqlDialect
> --------------------------------
>
> Key: CALCITE-1913
> URL: https://issues.apache.org/jira/browse/CALCITE-1913
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Affects Versions: 1.13.0
> Reporter: Jess Balint
> Assignee: Jess Balint
> Priority: Minor
>
> It would be useful to have the DB version # in the SqlDialect for unparsing
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
