Re: Distributed joins for JDBC
Added properties to .NET (https://issues.apache.org/jira/browse/IGNITE-3561 ). On Mon, Jul 25, 2016 at 1:23 PM, Andrey Gurawrote: > 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
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
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 Gurawrote: > 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
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 Vladykinwrote: > 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
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 Vladykinwrote: > 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
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
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? >