[jira] [Commented] (CALCITE-1253) Create Elasticsearch adapter for Calcite

2016-05-25 Thread Subhobrata Dey (JIRA) 

[ 
https://issues.apache.org/jira/browse/CALCITE-1253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15301483#comment-15301483
 ] 

Subhobrata Dey commented on CALCITE-1253:
-

Hello [~julianhyde],

I have fixed almost all the issues. Please review & accept the contribution.

1. Change type of ElasticsearchRel.Implementor.list from List> to List. The left field only exists because Mongo has two 
query modes: find and aggregate.

Issue fixed.

2. Simplify ElasticsearchToEnumerableConverter.implement, removing unused 
variables

Issue fixed.

3. Convert .json to standard json format (double-quoted identifiers and 
strings, see e.g. druid-wiki-model.json)

Issue fixed.

4. Fix bad grammar resulting from search replace of "a Mongo" to "a 
Elasticsearch", e.g. in "Enumerator that reads from a Elasticsearch type" 
should be "an Elasticsearch" not "a Elasticsearch". Review all comments for 
grammar.

Issue fixed.

5. There are not tests for each data type (e.g. integer not null, date, 
timestamp, boolean) so I expect there are bugs.

Kept it as part of next tasks for enhancing the tests with foodmart dataset.

6. In adapter spec, show how to write a query against a raw table (i.e. using 
the _map column). Your example pre-supposes that people have built views 
against the raw table, which is not valid.

Issue fixed.

7. In elasticsearch_adapter.md, remove trailing spaces

Issue fixed.

8. Fix indentation in java code, especially for long argument and parameter 
lists. "," should be at the end of a line, not the start.

Issue fixed.

9. ElasticsearchRules.maybeQuote not used; remove other unused methods and code

Issue fixed.

10. There are a few references to Bug.CALCITE_194_FIXED; makes no sense because 
this is bug on the Mongo adapter

Issue fixed.

11. I may be wrong, but it looks as if code has been copied the Mongo adapter 
that is not needed for tests to pass. Remove the code, or better, add tests.

Issue fixed by removing code.

12. I think there's a bug if I put a scalar expression into a project or filter 
that the adapter cannot handle during code generation, e.g. "select x + 1 from 
t", "select * from t where x + 1 > 10". For each of these, can you add tests if 
it works, or log a bug?

Will log a bug.

13. Can you briefly list what should be the next work? What are the bugs, 
missing features? They don't need to be fixed now, but I would like to know 
where the holes are.

- Enhance tests with foodmart dataset.
- Support aggregation operations. 

> Create Elasticsearch adapter for Calcite
> 
>
> Key: CALCITE-1253
> URL: https://issues.apache.org/jira/browse/CALCITE-1253
> Project: Calcite
>  Issue Type: New Feature
>Reporter: Subhobrata Dey
>Assignee: Julian Hyde
>
> This JIRA ticket is created to propose the addition of the new Elasticsearch 
> adapter for Calcite.
> The adapter exposes a SQL interface to elasticsearch which includes 
> projection, filtering, sort, fetch, offset queries.
> I have provided a couple of PRs, the first one is for the elasticsearch 
> adapter & the second one is for enhancing the Vagrantfile for loading test 
> data required for running the Junits.
> Currently, the support for aggregates is not provided. The work on it is in 
> progress.
> Kindly evaluate my contribution & please consider it as an addition to the 
> calcite project.
> Following PRs are provided:
> https://github.com/apache/calcite/pull/236
> https://github.com/vlsi/calcite-test-dataset/pull/10 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CALCITE-1257) Late-binding schema

2016-05-25 Thread Jesse Yates (JIRA) 

[ 
https://issues.apache.org/jira/browse/CALCITE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15301064#comment-15301064
 ] 

Jesse Yates commented on CALCITE-1257:
--

Feels like a lot of this is covered by the "EXTENDS" syntax, which covers both 
the expected field name and expected type. Only case that sits outside this 
seems to be {{SELECT *}}. What are you thinking for how this would look 
otherwise?

I'd also be interested in some way to late-bind field projection - i.e. user 
queries {{col1}}, but under the hood we transform that to {{column1, col1, c1}} 
based on how the table is functionally structured.

> Late-binding schema
> ---
>
> Key: CALCITE-1257
> URL: https://issues.apache.org/jira/browse/CALCITE-1257
> Project: Calcite
>  Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>
> Calcite should support late-binding schema, similar to what Drill does. 
> Currently if we query a schema-less database such as MongoDB or Elasticsearch 
> the best practice is to create a view that calls {{_MAP['fieldName']}} then 
> casts the result to the desired data type. Creating that view is a 
> significant effort. Certain tables should be flagged as having "late schema", 
> and when validating queries against those tables, users should be able to 
> reference any columns they like.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CALCITE-1257) Late-binding schema

2016-05-25 Thread Julian Hyde (JIRA) 
Julian Hyde created CALCITE-1257:


 Summary: Late-binding schema
 Key: CALCITE-1257
 URL: https://issues.apache.org/jira/browse/CALCITE-1257
 Project: Calcite
  Issue Type: Bug
Reporter: Julian Hyde
Assignee: Julian Hyde


Calcite should support late-binding schema, similar to what Drill does. 
Currently if we query a schema-less database such as MongoDB or Elasticsearch 
the best practice is to create a view that calls {{_MAP['fieldName']}} then 
casts the result to the desired data type. Creating that view is a significant 
effort. Certain tables should be flagged as having "late schema", and when 
validating queries against those tables, users should be able to reference any 
columns they like.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (CALCITE-1256) Quoted reserved identifier should match for column names

2016-05-25 Thread Jinfeng Ni (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CALCITE-1256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jinfeng Ni reassigned CALCITE-1256:
---

Assignee: Jinfeng Ni  (was: Julian Hyde)

> Quoted reserved identifier should match for column names
> 
>
> Key: CALCITE-1256
> URL: https://issues.apache.org/jira/browse/CALCITE-1256
> Project: Calcite
>  Issue Type: Bug
>Reporter: Jinfeng Ni
>Assignee: Jinfeng Ni
>
> SQL standard allows couple of reserved identifiers used for system function 
> call, such as USER, CURRENT_USER, CURRENT_TIME etc. If someone wants to use 
> those reserved names as column names, he has
> to use quoted identifier.
> However, Calcite always interprets those simple quoted identifiers as a 
> system function call, in stead of column name.  Such behavior is different 
> from Postgres/Oracle, which will interpret a quoted identifier as column 
> name, instead of system function call.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CALCITE-1245) Allow RelBuilder scan to take multiple arguments

2016-05-25 Thread Julian Hyde (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CALCITE-1245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Hyde resolved CALCITE-1245.
--
   Resolution: Fixed
Fix Version/s: 1.8.0

Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/b76affcc. Thanks 
for the PR, [~chris-baynes]!

> Allow RelBuilder scan to take multiple arguments
> 
>
> Key: CALCITE-1245
> URL: https://issues.apache.org/jira/browse/CALCITE-1245
> Project: Calcite
>  Issue Type: Improvement
>Reporter: Chris Baynes
>Assignee: Julian Hyde
> Fix For: 1.8.0
>
>
> Currently Relbuilder.scan takes a single tableName string argument, however 
> we'd like to use this to specify a sub-schema so we can use the Relbuilder to 
> construct our queries across datasources.
> The idea would be to change "scan(String tableName)" to "scan(String… 
> tableNames)", and add "scan(Iterable tableNames)".
> This is as discussed here: 
> http://mail-archives.apache.org/mod_mbox/calcite-dev/201605.mbox/%3CE4C0C38B-EDC2-4016-99C1-E7465AAC0C20%40apache.org%3E
> Opened this ticket so that we can submit a PR with the change.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CALCITE-1256) Quoted reserved identifier should match for column names

2016-05-25 Thread Jinfeng Ni (JIRA) 
Jinfeng Ni created CALCITE-1256:
---

 Summary: Quoted reserved identifier should match for column names
 Key: CALCITE-1256
 URL: https://issues.apache.org/jira/browse/CALCITE-1256
 Project: Calcite
  Issue Type: Bug
Reporter: Jinfeng Ni
Assignee: Julian Hyde


SQL standard allows couple of reserved identifiers used for system function 
call, such as USER, CURRENT_USER, CURRENT_TIME etc. If someone wants to use 
those reserved names as column names, he has
to use quoted identifier.

However, Calcite always interprets those simple quoted identifiers as a system 
function call, in stead of column name.  Such behavior is different from 
Postgres/Oracle, which will interpret a quoted identifier as column name, 
instead of system function call.





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CALCITE-1245) Allow RelBuilder scan to take multiple arguments

2016-05-25 Thread Chris Baynes (JIRA) 

[ 
https://issues.apache.org/jira/browse/CALCITE-1245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15299695#comment-15299695
 ] 

Chris Baynes commented on CALCITE-1245:
---

[~julianhyde] Have pushed again taking into account your suggestions, and 
squashed everything into a single commit (that seemed to me the way it has been 
done in other PRs).

> Allow RelBuilder scan to take multiple arguments
> 
>
> Key: CALCITE-1245
> URL: https://issues.apache.org/jira/browse/CALCITE-1245
> Project: Calcite
>  Issue Type: Improvement
>Reporter: Chris Baynes
>Assignee: Julian Hyde
>
> Currently Relbuilder.scan takes a single tableName string argument, however 
> we'd like to use this to specify a sub-schema so we can use the Relbuilder to 
> construct our queries across datasources.
> The idea would be to change "scan(String tableName)" to "scan(String… 
> tableNames)", and add "scan(Iterable tableNames)".
> This is as discussed here: 
> http://mail-archives.apache.org/mod_mbox/calcite-dev/201605.mbox/%3CE4C0C38B-EDC2-4016-99C1-E7465AAC0C20%40apache.org%3E
> Opened this ticket so that we can submit a PR with the change.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)