You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Andrey Mashenkov <an...@gmail.com> on 2022/05/20 10:55:49 UTC

Re: [DISCUSS] Query API for Ignite 3.0

JFYI. we have merged the initial version of SQL public API [1] and are
going to implement it in epic [2] and I've created few tickets on this.

Andey Gura, Taras Ledkov, Konstantine Orlov would you mind to share your
thoughts on implementation part in some IEP?
Is there IEP page created on the topic?

[1] https://issues.apache.org/jira/browse/IGNITE-15212
[2] https://issues.apache.org/jira/browse/IGNITE-16952

On Tue, Apr 6, 2021 at 4:23 PM Andrey Mashenkov <an...@gmail.com>
wrote:

> Hi Taras.
>
> 1. AFAIK, only Thin clients will be available in 3.0.
> However, yes, Native JDBC API is still "must have" on servers.
>
> 2. We won't have other projects in dependencies if possible. Unless
> we/they are Jigsaw compatible though.
>
> 2.1  I think it makes sense to be an R2DBC-compatible as it is a widely
> used framework. E.g. Spring supports R2DBC [1].
> Having an extension with R2DBC support will make Spring integration with
> Ignite easy in the future.
>
> If it will be enough to have a dependency on just reactive-streams API [2],
> then adding this API to dependencies looks ok to me, as there are only a
> few interfaces and converters to/from JDK Flow API.
> And the question is would we go with Flow API or Reactive-Streams?
>
> If we need some more than reactive-streams API, then I would suggest to go
> with Flow API.
>
> 2.2 ADBA is compatible with R2DBC but was discontinued [3].
>
> 2.3 I don't think custom API is ever useful. We will need
> converters/adapters to Flow or Reactive-streams for easy integration with
> other APIs/frameworks.
> Otherwise, uses will have difficulties interacting with Ignite in a
> reactive way.
>
> [1]
> https://spring.io/blog/2018/12/07/reactive-programming-and-relational-databases
> [2] https://github.com/reactive-streams/reactive-streams-jvm
> [3]
> https://mail.openjdk.java.net/pipermail/jdbc-spec-discuss/2019-September/000529.html
>
> On Tue, Apr 6, 2021 at 3:05 PM Taras Ledkov <tl...@gridgain.com> wrote:
>
>> Hi,
>>
>> Ignite 3.0 requires a rethinking of the query API.
>> We have 'cache.query()' and 'SqlFieldQuery' abstractions at the Ignite
>> 2.x native API and several JDBC implementation for clients.
>>
>> I propose to think about new query/SQL API for the Ignite 3.0.
>>
>> My vision is something like this:
>> Ignite will support two query APIs: standard JDBC (on native) and one of
>> reactive DB API.
>>
>> 1. Native JDBC API, e.g.:
>>      Connection conn = node.sql().connection(props);
>>
>> JDBC is the industrial standard of the DB access and we have to support
>> one.
>> Also:
>> 1.1. Thin JDBC client will be really thin: provide network communication
>> layer and transparently map to native API.
>> 1.2. Thick JDBC client implementation will be trivial: start client node
>> and open JDBC connection on the started node.
>> 1.3. JDBC provides sufficient functionality to implement ODBC (need to
>> investigate: may be thin protocol may be extended to unify JDBC and ODBC).
>>
>> 2. About reactive DB API.
>> I don't know of any industrial standard API for DB reactive access now.
>> There are several candidates:
>> 2.1. R2DBC look like the popular and alive. See [1];
>> 2.2. ADBA (java.sql2 [2]) looks like not alive. Not sure;
>> 2.3. Custom async/reactive API.
>> e.g. oracle DB use this way [3].
>>
>> Igniters, WDYT?
>>
>> [1]. https://github.com/r2dbc/r2dbc-spi
>> [2].
>> http://cr.openjdk.java.net/~lancea/apidoc/java/sql2/package-summary.html
>> [3].
>>
>> https://docs.oracle.com/en/database/oracle/oracle-database/21/jjdbc/jdbc-reactive-extensions.html#GUID-1C40C43B-3823-4848-8B5A-D2F97A82F79B
>>
>> --
>> Taras Ledkov
>> Mail-To: tledkov@gridgain.com
>>
>>
>
> --
> Best regards,
> Andrey V. Mashenkov
>


-- 
Best regards,
Andrey V. Mashenkov

Re: [DISCUSS] Query API for Ignite 3.0

Posted by Andrey Gura <ag...@apache.org>.
Andrey,

there is no IEP for Java API for SQL and would be great to have it.
I'll create the IEP soon.

On Fri, May 20, 2022 at 1:56 PM Andrey Mashenkov
<an...@gmail.com> wrote:
>
> JFYI. we have merged the initial version of SQL public API [1] and are
> going to implement it in epic [2] and I've created few tickets on this.
>
> Andey Gura, Taras Ledkov, Konstantine Orlov would you mind to share your
> thoughts on implementation part in some IEP?
> Is there IEP page created on the topic?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-15212
> [2] https://issues.apache.org/jira/browse/IGNITE-16952
>
> On Tue, Apr 6, 2021 at 4:23 PM Andrey Mashenkov <an...@gmail.com>
> wrote:
>
> > Hi Taras.
> >
> > 1. AFAIK, only Thin clients will be available in 3.0.
> > However, yes, Native JDBC API is still "must have" on servers.
> >
> > 2. We won't have other projects in dependencies if possible. Unless
> > we/they are Jigsaw compatible though.
> >
> > 2.1  I think it makes sense to be an R2DBC-compatible as it is a widely
> > used framework. E.g. Spring supports R2DBC [1].
> > Having an extension with R2DBC support will make Spring integration with
> > Ignite easy in the future.
> >
> > If it will be enough to have a dependency on just reactive-streams API [2],
> > then adding this API to dependencies looks ok to me, as there are only a
> > few interfaces and converters to/from JDK Flow API.
> > And the question is would we go with Flow API or Reactive-Streams?
> >
> > If we need some more than reactive-streams API, then I would suggest to go
> > with Flow API.
> >
> > 2.2 ADBA is compatible with R2DBC but was discontinued [3].
> >
> > 2.3 I don't think custom API is ever useful. We will need
> > converters/adapters to Flow or Reactive-streams for easy integration with
> > other APIs/frameworks.
> > Otherwise, uses will have difficulties interacting with Ignite in a
> > reactive way.
> >
> > [1]
> > https://spring.io/blog/2018/12/07/reactive-programming-and-relational-databases
> > [2] https://github.com/reactive-streams/reactive-streams-jvm
> > [3]
> > https://mail.openjdk.java.net/pipermail/jdbc-spec-discuss/2019-September/000529.html
> >
> > On Tue, Apr 6, 2021 at 3:05 PM Taras Ledkov <tl...@gridgain.com> wrote:
> >
> >> Hi,
> >>
> >> Ignite 3.0 requires a rethinking of the query API.
> >> We have 'cache.query()' and 'SqlFieldQuery' abstractions at the Ignite
> >> 2.x native API and several JDBC implementation for clients.
> >>
> >> I propose to think about new query/SQL API for the Ignite 3.0.
> >>
> >> My vision is something like this:
> >> Ignite will support two query APIs: standard JDBC (on native) and one of
> >> reactive DB API.
> >>
> >> 1. Native JDBC API, e.g.:
> >>      Connection conn = node.sql().connection(props);
> >>
> >> JDBC is the industrial standard of the DB access and we have to support
> >> one.
> >> Also:
> >> 1.1. Thin JDBC client will be really thin: provide network communication
> >> layer and transparently map to native API.
> >> 1.2. Thick JDBC client implementation will be trivial: start client node
> >> and open JDBC connection on the started node.
> >> 1.3. JDBC provides sufficient functionality to implement ODBC (need to
> >> investigate: may be thin protocol may be extended to unify JDBC and ODBC).
> >>
> >> 2. About reactive DB API.
> >> I don't know of any industrial standard API for DB reactive access now.
> >> There are several candidates:
> >> 2.1. R2DBC look like the popular and alive. See [1];
> >> 2.2. ADBA (java.sql2 [2]) looks like not alive. Not sure;
> >> 2.3. Custom async/reactive API.
> >> e.g. oracle DB use this way [3].
> >>
> >> Igniters, WDYT?
> >>
> >> [1]. https://github.com/r2dbc/r2dbc-spi
> >> [2].
> >> http://cr.openjdk.java.net/~lancea/apidoc/java/sql2/package-summary.html
> >> [3].
> >>
> >> https://docs.oracle.com/en/database/oracle/oracle-database/21/jjdbc/jdbc-reactive-extensions.html#GUID-1C40C43B-3823-4848-8B5A-D2F97A82F79B
> >>
> >> --
> >> Taras Ledkov
> >> Mail-To: tledkov@gridgain.com
> >>
> >>
> >
> > --
> > Best regards,
> > Andrey V. Mashenkov
> >
>
>
> --
> Best regards,
> Andrey V. Mashenkov