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 <sergi.vlady...@gmail.com>:
> 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 <sboi...@apache.org>:
>
>> 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?
>>
>
>
