[jira] [Commented] (CALCITE-1787) thetaSketch Support for Druid Adapter
[
https://issues.apache.org/jira/browse/CALCITE-1787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16051363#comment-16051363
]
Julian Hyde commented on CALCITE-1787:
--
I can't think of a case where "name" and "metricName" would be different for a
complex metric. (Unlike a regular metric, where there might be several metrics
that are different aggregate functions applied to the same argument: "select
sum(amount) as sum_amount, min(amount) as min_amount, hyperUnique(amount) as
hyper_amount, ...".)
> thetaSketch Support for Druid Adapter
> -
>
> Key: CALCITE-1787
> URL: https://issues.apache.org/jira/browse/CALCITE-1787
> Project: Calcite
> Issue Type: New Feature
> Components: druid
>Affects Versions: 1.12.0
>Reporter: Zain Humayun
>Assignee: Zain Humayun
>Priority: Minor
>
> Currently, the Druid adapter does not support the
> [thetaSketch|http://druid.io/docs/latest/development/extensions-core/datasketches-aggregators.html]
> aggregate type, which is used to measure the cardinality of a column
> quickly. Many Druid instances support theta sketches, so I think it would be
> a nice feature to have.
> I've been looking at the Druid adapter, and propose we add a new DruidType
> called {{thetaSketch}} and then add logic in the {{getJsonAggregation}}
> method in class {{DruidQuery}} to generate the {{thetaSketch}} aggregate.
> This will require accessing information about the columns (what data type
> they are) so that the thetaSketch aggregate is only produced if the column's
> type is {{thetaSketch}}.
> Also, I've noticed that a {{hyperUnique}} DruidType is currently defined, but
> a {{hyperUnique}} aggregate is never produced. Since both are approximate
> aggregators, I could also couple in the logic for {{hyperUnique}}.
> I'd love to hear your thoughts on my approach, and any suggestions you have
> for this feature.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CALCITE-1845) Quantified comparison predicates (SOME, ANY, ALL)
[
https://issues.apache.org/jira/browse/CALCITE-1845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1845:
-
Labels: phoenix (was: )
> Quantified comparison predicates (SOME, ANY, ALL)
> -
>
> Key: CALCITE-1845
> URL: https://issues.apache.org/jira/browse/CALCITE-1845
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
> Labels: phoenix
>
> Support quantified comparison predicates (SOME, ANY, ALL), per the SQL
> standard.
> {quote}
> ::=
>
> \|
> \|
> \|
> \|
> \|
> ::=
>
> \|
> ::= ALL
> ::=
> SOME
> \| ANY
> The result of “R T” is derived by the application of
> the implied “R RT” to every row RT in T.
> Case:
> * a) If T is empty or if the implied is True for every
> row RT in T, then “R T” is True.
> * b) If the implied is False for at least one row RT
> in T, then “R T” is False.
> * c) If the implied is True for at least one row RT in
> T, then “R T” is True.
> * d) If T is empty or if the implied is False for
> every row RT in T, then “R T” is False.
> * e) If “R T” is neither True nor False, then it is
> Unknown.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CALCITE-1845) Quantified comparison predicates (SOME, ANY, ALL)
Julian Hyde created CALCITE-1845:
Summary: Quantified comparison predicates (SOME, ANY, ALL)
Key: CALCITE-1845
URL: https://issues.apache.org/jira/browse/CALCITE-1845
Project: Calcite
Issue Type: Bug
Reporter: Julian Hyde
Assignee: Julian Hyde
Support quantified comparison predicates (SOME, ANY, ALL), per the SQL standard.
{quote}
::=
\|
\|
\|
\|
\|
::=
\|
::= ALL
::=
SOME
\| ANY
The result of “R T” is derived by the application of the
implied “R RT” to every row RT in T.
Case:
* a) If T is empty or if the implied is True for every
row RT in T, then “R T” is True.
* b) If the implied is False for at least one row RT in
T, then “R T” is False.
* c) If the implied is True for at least one row RT in
T, then “R T” is True.
* d) If T is empty or if the implied is False for every
row RT in T, then “R T” is False.
* e) If “R T” is neither True nor False, then it is
Unknown.
{quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1195) Create docs for interacting with Avatica server using json+curl
[
https://issues.apache.org/jira/browse/CALCITE-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16051303#comment-16051303
]
Josh Elser commented on CALCITE-1195:
-
You're also now marked as a contributor, [~risdenk] :)
> Create docs for interacting with Avatica server using json+curl
> ---
>
> Key: CALCITE-1195
> URL: https://issues.apache.org/jira/browse/CALCITE-1195
> Project: Calcite
> Issue Type: Task
> Components: avatica
>Reporter: Josh Elser
>Assignee: Kevin Risden
> Fix For: avatica-1.11.0
>
> Attachments: test_avatica_solr.sh
>
>
> A repeated problem I hear from people is that they are trying to use outdated
> CURL commands with JSON to "test" out the server.
> People will get to {{prepareAndExecute}} and then the query will fail.
> It appears that CALCITE-718 in 1.4.0-incubating changed the semantics of this
> request implementation to require a Statement to already exist in the server
> (by {{CreateStatement}}), whereas previous versions automatically created
> this Statement as a part of the call.
> We can get around this issue by just keep up-to-date docs on what the CURL
> commands to run are for simple actions.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (CALCITE-1195) Create docs for interacting with Avatica server using json+curl
[
https://issues.apache.org/jira/browse/CALCITE-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser reassigned CALCITE-1195:
---
Assignee: Kevin Risden (was: Josh Elser)
> Create docs for interacting with Avatica server using json+curl
> ---
>
> Key: CALCITE-1195
> URL: https://issues.apache.org/jira/browse/CALCITE-1195
> Project: Calcite
> Issue Type: Task
> Components: avatica
>Reporter: Josh Elser
>Assignee: Kevin Risden
> Fix For: avatica-1.11.0
>
> Attachments: test_avatica_solr.sh
>
>
> A repeated problem I hear from people is that they are trying to use outdated
> CURL commands with JSON to "test" out the server.
> People will get to {{prepareAndExecute}} and then the query will fail.
> It appears that CALCITE-718 in 1.4.0-incubating changed the semantics of this
> request implementation to require a Statement to already exist in the server
> (by {{CreateStatement}}), whereas previous versions automatically created
> this Statement as a part of the call.
> We can get around this issue by just keep up-to-date docs on what the CURL
> commands to run are for simple actions.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (CALCITE-1195) Create docs for interacting with Avatica server using json+curl
[
https://issues.apache.org/jira/browse/CALCITE-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved CALCITE-1195.
-
Resolution: Fixed
Committed in
https://git-wip-us.apache.org/repos/asf?p=calcite-avatica.git;a=commit;h=0020a547c845cc27f7dc048f2b8ac7cb83dc53e0
I published it at https://calcite.apache.org/avatica/docs/protocol_testing.html
after verifying that it works against the hsqldb avatica-1.10.0 docker image.
While there's always more we can do, this is a bit too broad to get anywhere
more with it. I should try to make more focused doc tickets in the future :)
> Create docs for interacting with Avatica server using json+curl
> ---
>
> Key: CALCITE-1195
> URL: https://issues.apache.org/jira/browse/CALCITE-1195
> Project: Calcite
> Issue Type: Task
> Components: avatica
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: avatica-1.11.0
>
> Attachments: test_avatica_solr.sh
>
>
> A repeated problem I hear from people is that they are trying to use outdated
> CURL commands with JSON to "test" out the server.
> People will get to {{prepareAndExecute}} and then the query will fail.
> It appears that CALCITE-718 in 1.4.0-incubating changed the semantics of this
> request implementation to require a Statement to already exist in the server
> (by {{CreateStatement}}), whereas previous versions automatically created
> this Statement as a part of the call.
> We can get around this issue by just keep up-to-date docs on what the CURL
> commands to run are for simple actions.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (CALCITE-1787) thetaSketch Support for Druid Adapter
[
https://issues.apache.org/jira/browse/CALCITE-1787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16051261#comment-16051261
]
Zain Humayun edited comment on CALCITE-1787 at 6/16/17 1:12 AM:
wouldn't the "metricName" field need to be there to tell calcite which sketch
to refer to? For example,
{code:none}
{
"name" : "user",
"type" : "hyperUnique",
"meticName" : "user_unique"
}
{code}
"user_unique" would not be exposed to the person writing the query, and an
error would be given if they tried to use it in a query. But, when "user" is
used correctly in a statement, say, count(distinct user), then the druid
adapter will know to use the "user_unique" column under the hood. In this case,
"user" is not actually a column in Druid anywhere, and "user_unique" is defined
as a metric in the Druid ingestion spec. Also, is there a specific existing
exception the adapter should throw?
was (Author: zhumayun):
wouldn't the "metricName" field need to be there to tell calcite which sketch
to refer to? For example,
{code:none}
{
"name" : "user",
"type" : "hyperUnique",
"meticName" : "user_unique"
}
{code}
"user_unique" would not be exposed to the user, and an error would be given if
they tried to use it in a query. But, when "user" is used correctly in a
statement, say, count(distinct user), then the druid adapter will know to use
the "user_unique" column under the hood. In this case, "user" is not actually a
column in Druid anywhere, and "user_unique" is defined as a metric in the Druid
ingestion spec. Also, is there a specific existing exception the adapter should
throw?
> thetaSketch Support for Druid Adapter
> -
>
> Key: CALCITE-1787
> URL: https://issues.apache.org/jira/browse/CALCITE-1787
> Project: Calcite
> Issue Type: New Feature
> Components: druid
>Affects Versions: 1.12.0
>Reporter: Zain Humayun
>Assignee: Zain Humayun
>Priority: Minor
>
> Currently, the Druid adapter does not support the
> [thetaSketch|http://druid.io/docs/latest/development/extensions-core/datasketches-aggregators.html]
> aggregate type, which is used to measure the cardinality of a column
> quickly. Many Druid instances support theta sketches, so I think it would be
> a nice feature to have.
> I've been looking at the Druid adapter, and propose we add a new DruidType
> called {{thetaSketch}} and then add logic in the {{getJsonAggregation}}
> method in class {{DruidQuery}} to generate the {{thetaSketch}} aggregate.
> This will require accessing information about the columns (what data type
> they are) so that the thetaSketch aggregate is only produced if the column's
> type is {{thetaSketch}}.
> Also, I've noticed that a {{hyperUnique}} DruidType is currently defined, but
> a {{hyperUnique}} aggregate is never produced. Since both are approximate
> aggregators, I could also couple in the logic for {{hyperUnique}}.
> I'd love to hear your thoughts on my approach, and any suggestions you have
> for this feature.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1787) thetaSketch Support for Druid Adapter
[
https://issues.apache.org/jira/browse/CALCITE-1787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16051261#comment-16051261
]
Zain Humayun commented on CALCITE-1787:
---
wouldn't the "metricName" field need to be there to tell calcite which sketch
to refer to? For example,
{code:none}
{
"name" : "user",
"type" : "hyperUnique",
"meticName" : "user_unique"
}
{code}
"user_unique" would not be exposed to the user, and an error would be given if
they tried to use it in a query. But, when "user" is used correctly in a
statement, say, count(distinct user), then the druid adapter will know to use
the "user_unique" column under the hood. In this case, "user" is not actually a
column in Druid anywhere, and "user_unique" is defined as a metric in the Druid
ingestion spec. Also, is there a specific existing exception the adapter should
throw?
> thetaSketch Support for Druid Adapter
> -
>
> Key: CALCITE-1787
> URL: https://issues.apache.org/jira/browse/CALCITE-1787
> Project: Calcite
> Issue Type: New Feature
> Components: druid
>Affects Versions: 1.12.0
>Reporter: Zain Humayun
>Assignee: Zain Humayun
>Priority: Minor
>
> Currently, the Druid adapter does not support the
> [thetaSketch|http://druid.io/docs/latest/development/extensions-core/datasketches-aggregators.html]
> aggregate type, which is used to measure the cardinality of a column
> quickly. Many Druid instances support theta sketches, so I think it would be
> a nice feature to have.
> I've been looking at the Druid adapter, and propose we add a new DruidType
> called {{thetaSketch}} and then add logic in the {{getJsonAggregation}}
> method in class {{DruidQuery}} to generate the {{thetaSketch}} aggregate.
> This will require accessing information about the columns (what data type
> they are) so that the thetaSketch aggregate is only produced if the column's
> type is {{thetaSketch}}.
> Also, I've noticed that a {{hyperUnique}} DruidType is currently defined, but
> a {{hyperUnique}} aggregate is never produced. Since both are approximate
> aggregators, I could also couple in the logic for {{hyperUnique}}.
> I'd love to hear your thoughts on my approach, and any suggestions you have
> for this feature.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1787) thetaSketch Support for Druid Adapter
[
https://issues.apache.org/jira/browse/CALCITE-1787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16051239#comment-16051239
]
Julian Hyde commented on CALCITE-1787:
--
I would remove the "metricName" field.
Consider the case of the "user" field. We would allow it to be queried via
"count(distinct user)" (if the "hyperUnique" metric exists) and maybe via
"where user > 1000" (if some kind of histogram sketch exists) but we would not
allow people to write "select user from table" because we do not store the raw
data for "user".
So, the "user" field is virtual. You can query certain expressions derived from
"user", but you cannot query it itself. That's why I would remove the
"metricName" field. A complex metric isn't derived from any other metric.
I know a virtual field is difficult concept for people to get their heads
around. But it creates a greater simplicity, because it means we are presenting
the data via the relational model. (Even though the relational data, the
original rows and columns, has been discarded.)
If someone tried to execute "select user from table", I would imagine that the
adapter would throw. But if people would prefer that "user" evaluates to some
expression, say 0, I could support that too.
> thetaSketch Support for Druid Adapter
> -
>
> Key: CALCITE-1787
> URL: https://issues.apache.org/jira/browse/CALCITE-1787
> Project: Calcite
> Issue Type: New Feature
> Components: druid
>Affects Versions: 1.12.0
>Reporter: Zain Humayun
>Assignee: Zain Humayun
>Priority: Minor
>
> Currently, the Druid adapter does not support the
> [thetaSketch|http://druid.io/docs/latest/development/extensions-core/datasketches-aggregators.html]
> aggregate type, which is used to measure the cardinality of a column
> quickly. Many Druid instances support theta sketches, so I think it would be
> a nice feature to have.
> I've been looking at the Druid adapter, and propose we add a new DruidType
> called {{thetaSketch}} and then add logic in the {{getJsonAggregation}}
> method in class {{DruidQuery}} to generate the {{thetaSketch}} aggregate.
> This will require accessing information about the columns (what data type
> they are) so that the thetaSketch aggregate is only produced if the column's
> type is {{thetaSketch}}.
> Also, I've noticed that a {{hyperUnique}} DruidType is currently defined, but
> a {{hyperUnique}} aggregate is never produced. Since both are approximate
> aggregators, I could also couple in the logic for {{hyperUnique}}.
> I'd love to hear your thoughts on my approach, and any suggestions you have
> for this feature.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1195) Create docs for interacting with Avatica server using json+curl
[
https://issues.apache.org/jira/browse/CALCITE-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16051186#comment-16051186
]
Kevin Risden commented on CALCITE-1195:
---
[~elserj] - Go for it :)
> Create docs for interacting with Avatica server using json+curl
> ---
>
> Key: CALCITE-1195
> URL: https://issues.apache.org/jira/browse/CALCITE-1195
> Project: Calcite
> Issue Type: Task
> Components: avatica
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: avatica-1.11.0
>
> Attachments: test_avatica_solr.sh
>
>
> A repeated problem I hear from people is that they are trying to use outdated
> CURL commands with JSON to "test" out the server.
> People will get to {{prepareAndExecute}} and then the query will fail.
> It appears that CALCITE-718 in 1.4.0-incubating changed the semantics of this
> request implementation to require a Statement to already exist in the server
> (by {{CreateStatement}}), whereas previous versions automatically created
> this Statement as a part of the call.
> We can get around this issue by just keep up-to-date docs on what the CURL
> commands to run are for simple actions.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1195) Create docs for interacting with Avatica server using json+curl
[
https://issues.apache.org/jira/browse/CALCITE-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16051182#comment-16051182
]
Josh Elser commented on CALCITE-1195:
-
Nice! Thanks for sharing that, Kevin.
Would you mind if I add this to the website?
> Create docs for interacting with Avatica server using json+curl
> ---
>
> Key: CALCITE-1195
> URL: https://issues.apache.org/jira/browse/CALCITE-1195
> Project: Calcite
> Issue Type: Task
> Components: avatica
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: avatica-1.11.0
>
> Attachments: test_avatica_solr.sh
>
>
> A repeated problem I hear from people is that they are trying to use outdated
> CURL commands with JSON to "test" out the server.
> People will get to {{prepareAndExecute}} and then the query will fail.
> It appears that CALCITE-718 in 1.4.0-incubating changed the semantics of this
> request implementation to require a Statement to already exist in the server
> (by {{CreateStatement}}), whereas previous versions automatically created
> this Statement as a part of the call.
> We can get around this issue by just keep up-to-date docs on what the CURL
> commands to run are for simple actions.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1787) thetaSketch Support for Druid Adapter
[
https://issues.apache.org/jira/browse/CALCITE-1787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16051104#comment-16051104
]
Zain Humayun commented on CALCITE-1787:
---
Recap and some implementation questions:
Columns of type thetaSketch/hyperUnique should be moved from the "metrics"
field to a new "complexMetrics" field from the model definition.
Each complex metric will have the form:
{code:none}
{
"name" : ,
"type" : ,
"meticName" :
}
{code}
This data will be saved into DruidTable. Note: while this information will be
provided by model definitions, calcite will have to rename any sketch columns
in the meta data query (when the model definition isn't available).
Calcite should reject any SQL statements that use the complex metrics in
correctly. Ideally, complex metrics should be able to indicate to validation
code what kind of statements they can be used in. Any ideas on the best way to
do so? Where is the best place to interrupt the validation process and check
for this kind of condition? At that point, we'll also need access to the
DruidTable because it will hold the information about the columns.
Once validation has finished, DruidQuery will be responsible for figuring out
that the actual column (sketch column) is based on the name and context in
which it's used.
I believe the most complicated part of this will be validation. Do you have any
general suggestions on where to start? I'm not very familiar with the
calcite-core code. Thanks.
> thetaSketch Support for Druid Adapter
> -
>
> Key: CALCITE-1787
> URL: https://issues.apache.org/jira/browse/CALCITE-1787
> Project: Calcite
> Issue Type: New Feature
> Components: druid
>Affects Versions: 1.12.0
>Reporter: Zain Humayun
>Assignee: Zain Humayun
>Priority: Minor
>
> Currently, the Druid adapter does not support the
> [thetaSketch|http://druid.io/docs/latest/development/extensions-core/datasketches-aggregators.html]
> aggregate type, which is used to measure the cardinality of a column
> quickly. Many Druid instances support theta sketches, so I think it would be
> a nice feature to have.
> I've been looking at the Druid adapter, and propose we add a new DruidType
> called {{thetaSketch}} and then add logic in the {{getJsonAggregation}}
> method in class {{DruidQuery}} to generate the {{thetaSketch}} aggregate.
> This will require accessing information about the columns (what data type
> they are) so that the thetaSketch aggregate is only produced if the column's
> type is {{thetaSketch}}.
> Also, I've noticed that a {{hyperUnique}} DruidType is currently defined, but
> a {{hyperUnique}} aggregate is never produced. Since both are approximate
> aggregators, I could also couple in the logic for {{hyperUnique}}.
> I'd love to hear your thoughts on my approach, and any suggestions you have
> for this feature.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (CALCITE-1844) Statistic getRowCount() should return Long
[ https://issues.apache.org/jira/browse/CALCITE-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde resolved CALCITE-1844. -- Resolution: Not A Problem > Statistic getRowCount() should return Long > --- > > Key: CALCITE-1844 > URL: https://issues.apache.org/jira/browse/CALCITE-1844 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: darion yaphet >Assignee: Julian Hyde > > Currently Statistic.getRowCount() return a double type data as the > approximate number of rows in the table . It seems should be a Long type . > And I found the row count is estimate value , use long type maybe better ? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1844) Statistic getRowCount() should return Long
[ https://issues.apache.org/jira/browse/CALCITE-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16050751#comment-16050751 ] Julian Hyde commented on CALCITE-1844: -- I made it a Double because it is an estimate (in statistics it is an expected value, i.e. an average). If you have two sources of estimates and one says 0 and the other says 1, then the best combined estimate is 0.5. Also, using Double means we don't have to worry about overflowing 2^63. Estimates that large are not as uncommon as you think. > Statistic getRowCount() should return Long > --- > > Key: CALCITE-1844 > URL: https://issues.apache.org/jira/browse/CALCITE-1844 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: darion yaphet >Assignee: Julian Hyde > > Currently Statistic.getRowCount() return a double type data as the > approximate number of rows in the table . It seems should be a Long type . > And I found the row count is estimate value , use long type maybe better ? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1841) Create handlers for Jdbc dialect specific generated sql
[
https://issues.apache.org/jira/browse/CALCITE-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16050400#comment-16050400
]
Chris Baynes commented on CALCITE-1841:
---
bq. Why not do this before unparsing by transforming the SqlNode tree?
Since most of the dialect specific changes are related to the name of the
function or things like the order of parameters, I think it would be nice to
have handlers like OracleSqlFloorFunction & MysqlSqlFloorFunction. The easiest
way to hook those up afaik is for them to implement the unparse method.
Once inside the unparse method the SqlCall can of course be transformed, but
doing this outside of dialect specific code gets ugly since you have to use
specific strings which are of course not defined anywhere in calcite as enums
or in operator tables ("DATE_TRUNC", "", "MM", etc).
What implementation did you have in mind?
> Create handlers for Jdbc dialect specific generated sql
> ---
>
> Key: CALCITE-1841
> URL: https://issues.apache.org/jira/browse/CALCITE-1841
> Project: Calcite
> Issue Type: Improvement
> Components: jdbc-adapter
>Reporter: Chris Baynes
>Assignee: Julian Hyde
>
> Currently the only way to generate different sql for dialects is to switch on
> the dialect in the unparse method. This is used quite heavily in e.g.
> SqlFloorFunction, but there are also switches in:
> * SUBSTRING()
> * SqlDateLiteral quoting
> * SqlTimestampLiteral quoting
> * Dialects using different interval literals (e.g. Hsqldb uses & MM
> rather than YEAR & MONTH)
> * limit/offset construction
> * mysql isnull function
> * type differences (*)
> It would be great to have dialect specific handlers to deal with these,
> making testing & addition of new handlers (new dialects, or new overrides for
> a given function) much easier in the future.
> One suggested path to approach this:
> https://issues.apache.org/jira/browse/CALCITE-1798?focusedCommentId=16031609=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16031609
> (*) There is a comment in SqlImplementor that reads "MySQL doesn't have a
> VARCHAR type, only CHAR.". Not sure if this was for a very old version of
> mysql, but it's certainly not true anymore.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CALCITE-1844) Statistic getRowCount() should return Long
[ https://issues.apache.org/jira/browse/CALCITE-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] darion yaphet updated CALCITE-1844: --- Description: Currently Statistic.getRowCount() return a double type data as the approximate number of rows in the table . It seems should be a Long type . And I found the row count is estimate value , use long type maybe better ? (was: Currently Statistic.getRowCount() return a double type data as the approximate number of rows in the table . It seems should be a Long type .) > Statistic getRowCount() should return Long > --- > > Key: CALCITE-1844 > URL: https://issues.apache.org/jira/browse/CALCITE-1844 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: darion yaphet >Assignee: Julian Hyde > > Currently Statistic.getRowCount() return a double type data as the > approximate number of rows in the table . It seems should be a Long type . > And I found the row count is estimate value , use long type maybe better ? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CALCITE-1844) Statistic getRowCount() should return Long
darion yaphet created CALCITE-1844: -- Summary: Statistic getRowCount() should return Long Key: CALCITE-1844 URL: https://issues.apache.org/jira/browse/CALCITE-1844 Project: Calcite Issue Type: Bug Components: core Reporter: darion yaphet Assignee: Julian Hyde Currently Statistic.getRowCount() return a double type data as the approximate number of rows in the table . It seems should be a Long type . -- This message was sent by Atlassian JIRA (v6.4.14#64029)
