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?
>
