Calcite jdbc driver dependencies

2016-11-20 Thread Christian Tzolov 
Hi,

I've been working on Calcite adapter for a nosql datastore.

The prototype works fine when i test it with the Sqlline command line tool.
But it is not entirely clear how to use it through a jdbc driver from 3rd
party tools. I've read the avatica docs but not sure if i'm getting it
right.

For the loca jdbc driver case do i need build my adapter as an uber jar to
bundle all necessary dependencies? If so are there any examples around?

For the remote jdbc mode do i need to create and build a customer avatica
server that pulls my adapters dependencies?

I am sorry if this question has been answered already

Cheers,
Christian

Re: Calcite jdbc driver dependencies

2016-11-20 Thread Christian Tzolov 
FYI, the uber jar jdbc did the job

On 20 November 2016 at 22:34, Christian Tzolov  wrote:

> Hi,
>
> I've been working on Calcite adapter for a nosql datastore.
>
> The prototype works fine when i test it with the Sqlline command line
> tool. But it is not entirely clear how to use it through a jdbc driver from
> 3rd party tools. I've read the avatica docs but not sure if i'm getting it
> right.
>
> For the loca jdbc driver case do i need build my adapter as an uber jar to
> bundle all necessary dependencies? If so are there any examples around?
>
> For the remote jdbc mode do i need to create and build a customer avatica
> server that pulls my adapters dependencies?
>
> I am sorry if this question has been answered already
>
> Cheers,
> Christian
>
>


-- 
Christian Tzolov  | Solution Architect,
EMEA Practice Team | Pivotal 
ctzo...@pivotal.io|+31610285517

Re: Calcite jdbc driver dependencies

2016-11-20 Thread Christian Tzolov 
The uberized jdbc adapter fails with "Unable to instantiate java compiler"
when i try it with tools like DbVisualizer or SQurriel .

Noticed same error has been discussed in two others thread but there is no
resolution. In my case the adapter pom contains a single janino-2.7.6
dependency (via the calcite-core).

Could this be related to the maven-shade-plugin configuration?


On 20 November 2016 at 23:52, Christian Tzolov  wrote:

> FYI, the uber jar jdbc did the job
>
> On 20 November 2016 at 22:34, Christian Tzolov  wrote:
>
>> Hi,
>>
>> I've been working on Calcite adapter for a nosql datastore.
>>
>> The prototype works fine when i test it with the Sqlline command line
>> tool. But it is not entirely clear how to use it through a jdbc driver from
>> 3rd party tools. I've read the avatica docs but not sure if i'm getting it
>> right.
>>
>> For the loca jdbc driver case do i need build my adapter as an uber jar
>> to bundle all necessary dependencies? If so are there any examples around?
>>
>> For the remote jdbc mode do i need to create and build a customer avatica
>> server that pulls my adapters dependencies?
>>
>> I am sorry if this question has been answered already
>>
>> Cheers,
>> Christian
>>
>>
>
>
>
>

Re: Calcite jdbc driver dependencies

2016-11-20 Thread Christian Tzolov 
The underlying exception causing the "Unable to instantiate java
compiler" seems
to be:

*Caused by: java.lang.ClassNotFoundException: No implementation of
org.codehaus.commons.compiler is on the class path. Typically, you'd have
'janino.jar', or 'commons-compiler-jdk.jar', or both on the classpath.*
* at
org.codehaus.commons.compiler.CompilerFactoryFactory.getDefaultCompilerFactory(CompilerFactoryFactory.java:59)*

* at
org.apache.calcite.rel.metadata.JaninoRelMetadataProvider.compile(JaninoRelMetadataProvider.java:425)*
I've tried to manually add the 'janino.jar' and 'commons-compiler-jdk.jar'
jars as well as excluding them from the uber jdbc jar. But the error is
still there

On 21 November 2016 at 00:18, Christian Tzolov  wrote:

> The uberized jdbc adapter fails with "Unable to instantiate java compiler"
> when i try it with tools like DbVisualizer or SQurriel .
>
> Noticed same error has been discussed in two others thread but there is no
> resolution. In my case the adapter pom contains a single janino-2.7.6
> dependency (via the calcite-core).
>
> Could this be related to the maven-shade-plugin configuration?
>
>
> On 20 November 2016 at 23:52, Christian Tzolov  wrote:
>
>> FYI, the uber jar jdbc did the job
>>
>> On 20 November 2016 at 22:34, Christian Tzolov 
>> wrote:
>>
>>> Hi,
>>>
>>> I've been working on Calcite adapter for a nosql datastore.
>>>
>>> The prototype works fine when i test it with the Sqlline command line
>>> tool. But it is not entirely clear how to use it through a jdbc driver from
>>> 3rd party tools. I've read the avatica docs but not sure if i'm getting it
>>> right.
>>>
>>> For the loca jdbc driver case do i need build my adapter as an uber jar
>>> to bundle all necessary dependencies? If so are there any examples around?
>>>
>>> For the remote jdbc mode do i need to create and build a customer
>>> avatica server that pulls my adapters dependencies?
>>>
>>> I am sorry if this question has been answered already
>>>
>>> Cheers,
>>> Christian
>>>
>>>
>>
>>
>>
>>
>
>

[jira] [Created] (CALCITE-1498) RelMdUtil.checkInputForCollationAndLimit() should also consider input collations as a zero-length collation list.

2016-11-20 Thread Maryann Xue (JIRA) 
Maryann Xue created CALCITE-1498:


 Summary: RelMdUtil.checkInputForCollationAndLimit() should also 
consider input collations as a zero-length collation list.
 Key: CALCITE-1498
 URL: https://issues.apache.org/jira/browse/CALCITE-1498
 Project: Calcite
  Issue Type: Bug
  Components: core
Affects Versions: 1.10.0
Reporter: Maryann Xue
Assignee: Maryann Xue
Priority: Minor


{code}
// Check if the input is already sorted
boolean alreadySorted = false;
if (!alreadySorted) {
  for (RelCollation inputCollation : mq.collations(input)) {
if (inputCollation.satisfies(collation)) {
  alreadySorted = true;
  break;
}
  }
}
{code}
if {{mq.collations(input)}} returns an empty array, {{alreadySorted}} will 
always be false even if the required {{collation}} is an empty collation (which 
indicates there's no need to sort).



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

[jira] [Created] (CALCITE-1499) Add an option to exclude VolcanoPlanner's "originalRoot" from planning process

2016-11-20 Thread Maryann Xue (JIRA) 
Maryann Xue created CALCITE-1499:


 Summary: Add an option to exclude VolcanoPlanner's "originalRoot" 
from planning process
 Key: CALCITE-1499
 URL: https://issues.apache.org/jira/browse/CALCITE-1499
 Project: Calcite
  Issue Type: Improvement
  Components: core
Affects Versions: 1.10.0
Reporter: Maryann Xue
Assignee: Maryann Xue


The Calcite compilation framework runs a series of Programs for query planning. 
The default programs consist of some pre-processing HepPrograms, e.g., 
de-correlation, field-trimming, etc.,  the volcano planning program, and some 
post-processing HepPrograms. In {{Prepare.optimize()}}, {{planner.setRoot()}} 
is called before running the programs. As a result, the original rel from 
sql-to-rel conversion becomes the "originalRoot" in the VolcanoPlanner, and the 
new rel from the pre-processing programs becomes the new "root". In some cases, 
we would only want to run volcano planning on the new root based on the 
assumption that the new root is the desired form after pre-processing. And if 
we have an option to turn off the planning of the original root, the planning 
space can be significantly reduced.



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

[jira] [Created] (CALCITE-1500) Allow materialization-applied rels to run pre-processing programs

2016-11-20 Thread Maryann Xue (JIRA) 
Maryann Xue created CALCITE-1500:


 Summary: Allow materialization-applied rels to run pre-processing 
programs
 Key: CALCITE-1500
 URL: https://issues.apache.org/jira/browse/CALCITE-1500
 Project: Calcite
  Issue Type: Improvement
  Components: core
Affects Versions: 1.10.0
Reporter: Maryann Xue
Assignee: Maryann Xue


VolcanoPlanner now takes the "originalRoot" as the input for materialized-view 
substitution, so the programs used in {{Prepare.optimize()}} will not be 
applied to these substituted rels. For example, a correlated subquery will be 
de-correlated but its equivalents with materialization substitutions will not 
be de-correlated. So it would be nice to have a way for the substituted rels to 
run specific programs too before starting volcano planning.
The easiest solution might be using the new "root" for materialization 
substitution instead, but it would be based on the assumption that those 
"pre-processing" programs are simple ones like de-correlation and 
field-trimming. In order to allow a more general pre-processing program set, 
one that could have different optimization output for the original rel and for 
the materialization substituted rels, we'd better have an interface or some 
approach to run pre-processing programs for rels after materialization 
substitution.



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