Re: Distributed joins for JDBC

2016-07-25 Thread Pavel Tupitsyn
Added properties to .NET (https://issues.apache.org/jira/browse/IGNITE-3561
).

On Mon, Jul 25, 2016 at 1:23 PM, Andrey Gura  wrote:

> Implemented. See corresponding ticket.
>
> Not supported by Java client based driver because it is deprecated and does
> not support any SqlFieldQuery properties. If we want support this property
> (and may be other, like local and collocated) in Java client based driver
> then we should implement it as separate task.
>
> On Mon, Jul 25, 2016 at 10:32 AM, Andrey Gura  wrote:
>
> > Our JDBC drivers already have connection properties that correspond to
> > SqlFieldsQuery properties. So we can just add support of this parameter
> to
> > connection string parser.
> >
> > Corresponding ticket created IGNITE-3563 (
> > https://issues.apache.org/jira/browse/IGNITE-3563 ).
> >
> > On Mon, Jul 25, 2016 at 10:04 AM, Sergi Vladykin <
> sergi.vlady...@gmail.com
> > > wrote:
> >
> >> I don't think it makes sense to extend JDBC this way because usually if
> >> one
> >> have access to Java API he most probably will use Ignite API. If for
> some
> >> reason they use JDBC it means that it is an application which was aimed
> to
> >> work with any RDBMS and should not know about quirks of some particular
> >> driver. Take any JDBC based SQL console for example, we have to support
> >> them out of the box.
> >>
> >> I think we should have a connection options which we can append to JDBC
> >> URL
> >> like it is done in H2:
> >>
> >> jdbc:h2:my_database;OPTION1=bla;OPTION2=blabla
> >>
> >> In our case it must be something like DISTRIBUTED_JOINS=true and it will
> >> affect the whole connection.
> >>
> >> Of course we have to support simultaneous connections to the same DB
> with
> >> different options.
> >>
> >> Sergi
> >>
> >>
> >> 2016-07-25 9:19 GMT+03:00 Semyon Boikov :
> >>
> >> > Hi,
> >> >
> >> > Last week distributed joins functionality was merged, but one thing
> was
> >> > overlooked. Distributed joins should be explicitly enabled using using
> >> > method 'setDistributedJoins' available in java API
> >> > (SqlQuery/SqlFieldsQuery). First, this parameter should be also added
> in
> >> > .Net/C++/REST API, this is straightforward. Also there should be
> >> > possibility to enable distributed joins for JDBC API. Does it make
> >> sense to
> >> > add Ignite-specific interface extending standard java.sql.Statement,
> so
> >> > 'setDistributedJoins' method can be added there.
> >> > JDBC API already have 'unwrap' method to deal with vendor-specific
> >> > interfaces, code will look like this:
> >> > * IgniteStatement stmt =
> >> > connection.createStatement().unwrap(IgniteStatement.class);*
> >> > * stmt.setDistributedJoins(true);*
> >> > *stmt.executeQuery("...");*
> >> >
> >> > What do you think?
> >> >
> >>
> >
> >
> >
> > --
> > Andrey Gura
> > GridGain Systems, Inc.
> > www.gridgain.com
> >
>
>
>
> --
> Andrey Gura
> GridGain Systems, Inc.
> www.gridgain.com
>


Re: Distributed joins for JDBC

2016-07-25 Thread Sergi Vladykin
Pavel,

There are two reasons for this:
1. This setting may affect performance for all the cases you mentioned,
because it does much more complex query optimization.
2. This feature is quite new and I want to release it in the safest
possible way because we may just brake existing applications if we enable
it always.

Andrey,

Good news!

Sergi




2016-07-25 10:32 GMT+03:00 Andrey Gura :

> Our JDBC drivers already have connection properties that correspond to
> SqlFieldsQuery properties. So we can just add support of this parameter to
> connection string parser.
>
> Corresponding ticket created IGNITE-3563 (
> https://issues.apache.org/jira/browse/IGNITE-3563 ).
>
> On Mon, Jul 25, 2016 at 10:04 AM, Sergi Vladykin  >
> wrote:
>
> > I don't think it makes sense to extend JDBC this way because usually if
> one
> > have access to Java API he most probably will use Ignite API. If for some
> > reason they use JDBC it means that it is an application which was aimed
> to
> > work with any RDBMS and should not know about quirks of some particular
> > driver. Take any JDBC based SQL console for example, we have to support
> > them out of the box.
> >
> > I think we should have a connection options which we can append to JDBC
> URL
> > like it is done in H2:
> >
> > jdbc:h2:my_database;OPTION1=bla;OPTION2=blabla
> >
> > In our case it must be something like DISTRIBUTED_JOINS=true and it will
> > affect the whole connection.
> >
> > Of course we have to support simultaneous connections to the same DB with
> > different options.
> >
> > Sergi
> >
> >
> > 2016-07-25 9:19 GMT+03:00 Semyon Boikov :
> >
> > > Hi,
> > >
> > > Last week distributed joins functionality was merged, but one thing was
> > > overlooked. Distributed joins should be explicitly enabled using using
> > > method 'setDistributedJoins' available in java API
> > > (SqlQuery/SqlFieldsQuery). First, this parameter should be also added
> in
> > > .Net/C++/REST API, this is straightforward. Also there should be
> > > possibility to enable distributed joins for JDBC API. Does it make
> sense
> > to
> > > add Ignite-specific interface extending standard java.sql.Statement, so
> > > 'setDistributedJoins' method can be added there.
> > > JDBC API already have 'unwrap' method to deal with vendor-specific
> > > interfaces, code will look like this:
> > > * IgniteStatement stmt =
> > > connection.createStatement().unwrap(IgniteStatement.class);*
> > > * stmt.setDistributedJoins(true);*
> > > *stmt.executeQuery("...");*
> > >
> > > What do you think?
> > >
> >
>
>
>
> --
> Andrey Gura
> GridGain Systems, Inc.
> www.gridgain.com
>


Re: Distributed joins for JDBC

2016-07-25 Thread Alexey Kuznetsov
Why we need to *TURN ON/OFF* this mode?
Why not have it always *ON*?

On Mon, Jul 25, 2016 at 2:32 PM, Andrey Gura  wrote:

> Our JDBC drivers already have connection properties that correspond to
> SqlFieldsQuery properties. So we can just add support of this parameter to
> connection string parser.
>
> Corresponding ticket created IGNITE-3563 (
> https://issues.apache.org/jira/browse/IGNITE-3563 ).
>
> On Mon, Jul 25, 2016 at 10:04 AM, Sergi Vladykin  >
> wrote:
>
> > I don't think it makes sense to extend JDBC this way because usually if
> one
> > have access to Java API he most probably will use Ignite API. If for some
> > reason they use JDBC it means that it is an application which was aimed
> to
> > work with any RDBMS and should not know about quirks of some particular
> > driver. Take any JDBC based SQL console for example, we have to support
> > them out of the box.
> >
> > I think we should have a connection options which we can append to JDBC
> URL
> > like it is done in H2:
> >
> > jdbc:h2:my_database;OPTION1=bla;OPTION2=blabla
> >
> > In our case it must be something like DISTRIBUTED_JOINS=true and it will
> > affect the whole connection.
> >
> > Of course we have to support simultaneous connections to the same DB with
> > different options.
> >
> > Sergi
> >
> >
> > 2016-07-25 9:19 GMT+03:00 Semyon Boikov :
> >
> > > Hi,
> > >
> > > Last week distributed joins functionality was merged, but one thing was
> > > overlooked. Distributed joins should be explicitly enabled using using
> > > method 'setDistributedJoins' available in java API
> > > (SqlQuery/SqlFieldsQuery). First, this parameter should be also added
> in
> > > .Net/C++/REST API, this is straightforward. Also there should be
> > > possibility to enable distributed joins for JDBC API. Does it make
> sense
> > to
> > > add Ignite-specific interface extending standard java.sql.Statement, so
> > > 'setDistributedJoins' method can be added there.
> > > JDBC API already have 'unwrap' method to deal with vendor-specific
> > > interfaces, code will look like this:
> > > * IgniteStatement stmt =
> > > connection.createStatement().unwrap(IgniteStatement.class);*
> > > * stmt.setDistributedJoins(true);*
> > > *stmt.executeQuery("...");*
> > >
> > > What do you think?
> > >
> >
>
>
>
> --
> Andrey Gura
> GridGain Systems, Inc.
> www.gridgain.com
>



-- 
Alexey Kuznetsov
GridGain Systems
www.gridgain.com


Re: Distributed joins for JDBC

2016-07-25 Thread Andrey Gura
Our JDBC drivers already have connection properties that correspond to
SqlFieldsQuery properties. So we can just add support of this parameter to
connection string parser.

Corresponding ticket created IGNITE-3563 (
https://issues.apache.org/jira/browse/IGNITE-3563 ).

On Mon, Jul 25, 2016 at 10:04 AM, Sergi Vladykin 
wrote:

> I don't think it makes sense to extend JDBC this way because usually if one
> have access to Java API he most probably will use Ignite API. If for some
> reason they use JDBC it means that it is an application which was aimed to
> work with any RDBMS and should not know about quirks of some particular
> driver. Take any JDBC based SQL console for example, we have to support
> them out of the box.
>
> I think we should have a connection options which we can append to JDBC URL
> like it is done in H2:
>
> jdbc:h2:my_database;OPTION1=bla;OPTION2=blabla
>
> In our case it must be something like DISTRIBUTED_JOINS=true and it will
> affect the whole connection.
>
> Of course we have to support simultaneous connections to the same DB with
> different options.
>
> Sergi
>
>
> 2016-07-25 9:19 GMT+03:00 Semyon Boikov :
>
> > Hi,
> >
> > Last week distributed joins functionality was merged, but one thing was
> > overlooked. Distributed joins should be explicitly enabled using using
> > method 'setDistributedJoins' available in java API
> > (SqlQuery/SqlFieldsQuery). First, this parameter should be also added in
> > .Net/C++/REST API, this is straightforward. Also there should be
> > possibility to enable distributed joins for JDBC API. Does it make sense
> to
> > add Ignite-specific interface extending standard java.sql.Statement, so
> > 'setDistributedJoins' method can be added there.
> > JDBC API already have 'unwrap' method to deal with vendor-specific
> > interfaces, code will look like this:
> > * IgniteStatement stmt =
> > connection.createStatement().unwrap(IgniteStatement.class);*
> > * stmt.setDistributedJoins(true);*
> > *stmt.executeQuery("...");*
> >
> > What do you think?
> >
>



-- 
Andrey Gura
GridGain Systems, Inc.
www.gridgain.com


Re: Distributed joins for JDBC

2016-07-25 Thread Pavel Tupitsyn
Hi,

I've added IGNITE-3561 for .NET.

However, there is not enough documentation for the new property:

* What are the implications of enabling distributed joins?
* Does it affect performance of non-join queries?
* Does it affect performance of colocated joins?
* Why is it disabled by default? Can we just enable it always and remove
the property?

Pavel.


On Mon, Jul 25, 2016 at 10:07 AM, Sergi Vladykin 
wrote:

> BTW this approach will be applicable to ODBC as well as far as I
> understand, so it will be consistent.
>
> Sergi
>
> 2016-07-25 10:04 GMT+03:00 Sergi Vladykin :
>
> > I don't think it makes sense to extend JDBC this way because usually if
> > one have access to Java API he most probably will use Ignite API. If for
> > some reason they use JDBC it means that it is an application which was
> > aimed to work with any RDBMS and should not know about quirks of some
> > particular driver. Take any JDBC based SQL console for example, we have
> to
> > support them out of the box.
> >
> > I think we should have a connection options which we can append to JDBC
> > URL like it is done in H2:
> >
> > jdbc:h2:my_database;OPTION1=bla;OPTION2=blabla
> >
> > In our case it must be something like DISTRIBUTED_JOINS=true and it will
> > affect the whole connection.
> >
> > Of course we have to support simultaneous connections to the same DB with
> > different options.
> >
> > Sergi
> >
> >
> > 2016-07-25 9:19 GMT+03:00 Semyon Boikov :
> >
> >> Hi,
> >>
> >> Last week distributed joins functionality was merged, but one thing was
> >> overlooked. Distributed joins should be explicitly enabled using using
> >> method 'setDistributedJoins' available in java API
> >> (SqlQuery/SqlFieldsQuery). First, this parameter should be also added in
> >> .Net/C++/REST API, this is straightforward. Also there should be
> >> possibility to enable distributed joins for JDBC API. Does it make sense
> >> to
> >> add Ignite-specific interface extending standard java.sql.Statement, so
> >> 'setDistributedJoins' method can be added there.
> >> JDBC API already have 'unwrap' method to deal with vendor-specific
> >> interfaces, code will look like this:
> >> * IgniteStatement stmt =
> >> connection.createStatement().unwrap(IgniteStatement.class);*
> >> * stmt.setDistributedJoins(true);*
> >> *stmt.executeQuery("...");*
> >>
> >> What do you think?
> >>
> >
> >
>


Re: Distributed joins for JDBC

2016-07-25 Thread Sergi Vladykin
BTW this approach will be applicable to ODBC as well as far as I
understand, so it will be consistent.

Sergi

2016-07-25 10:04 GMT+03:00 Sergi Vladykin :

> I don't think it makes sense to extend JDBC this way because usually if
> one have access to Java API he most probably will use Ignite API. If for
> some reason they use JDBC it means that it is an application which was
> aimed to work with any RDBMS and should not know about quirks of some
> particular driver. Take any JDBC based SQL console for example, we have to
> support them out of the box.
>
> I think we should have a connection options which we can append to JDBC
> URL like it is done in H2:
>
> jdbc:h2:my_database;OPTION1=bla;OPTION2=blabla
>
> In our case it must be something like DISTRIBUTED_JOINS=true and it will
> affect the whole connection.
>
> Of course we have to support simultaneous connections to the same DB with
> different options.
>
> Sergi
>
>
> 2016-07-25 9:19 GMT+03:00 Semyon Boikov :
>
>> Hi,
>>
>> Last week distributed joins functionality was merged, but one thing was
>> overlooked. Distributed joins should be explicitly enabled using using
>> method 'setDistributedJoins' available in java API
>> (SqlQuery/SqlFieldsQuery). First, this parameter should be also added in
>> .Net/C++/REST API, this is straightforward. Also there should be
>> possibility to enable distributed joins for JDBC API. Does it make sense
>> to
>> add Ignite-specific interface extending standard java.sql.Statement, so
>> 'setDistributedJoins' method can be added there.
>> JDBC API already have 'unwrap' method to deal with vendor-specific
>> interfaces, code will look like this:
>> * IgniteStatement stmt =
>> connection.createStatement().unwrap(IgniteStatement.class);*
>> * stmt.setDistributedJoins(true);*
>> *stmt.executeQuery("...");*
>>
>> What do you think?
>>
>
>


Re: Distributed joins for JDBC

2016-07-25 Thread Sergi Vladykin
I don't think it makes sense to extend JDBC this way because usually if one
have access to Java API he most probably will use Ignite API. If for some
reason they use JDBC it means that it is an application which was aimed to
work with any RDBMS and should not know about quirks of some particular
driver. Take any JDBC based SQL console for example, we have to support
them out of the box.

I think we should have a connection options which we can append to JDBC URL
like it is done in H2:

jdbc:h2:my_database;OPTION1=bla;OPTION2=blabla

In our case it must be something like DISTRIBUTED_JOINS=true and it will
affect the whole connection.

Of course we have to support simultaneous connections to the same DB with
different options.

Sergi


2016-07-25 9:19 GMT+03:00 Semyon Boikov :

> Hi,
>
> Last week distributed joins functionality was merged, but one thing was
> overlooked. Distributed joins should be explicitly enabled using using
> method 'setDistributedJoins' available in java API
> (SqlQuery/SqlFieldsQuery). First, this parameter should be also added in
> .Net/C++/REST API, this is straightforward. Also there should be
> possibility to enable distributed joins for JDBC API. Does it make sense to
> add Ignite-specific interface extending standard java.sql.Statement, so
> 'setDistributedJoins' method can be added there.
> JDBC API already have 'unwrap' method to deal with vendor-specific
> interfaces, code will look like this:
> * IgniteStatement stmt =
> connection.createStatement().unwrap(IgniteStatement.class);*
> * stmt.setDistributedJoins(true);*
> *stmt.executeQuery("...");*
>
> What do you think?
>