[jira] [Created] (IGNITE-14494) .NET: Problem with collection de/serialization

[Yaroslav Molochkov (Jira)]

Yaroslav Molochkov created IGNITE-14494:
---

 Summary: .NET: Problem with collection de/serialization
 Key: IGNITE-14494
 URL: https://issues.apache.org/jira/browse/IGNITE-14494
 Project: Ignite
  Issue Type: Bug
Reporter: Yaroslav Molochkov
 Attachments: UnitTest.cs

Reproducer is attached. Basically the problem surfaces when you call service's 
method via proxy. The method is supposed to return a collection type result.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Review for IGNITE-13112 The current security context should be obtained using the IgniteSecurity interface only.

[Denis Garus]

Hello, Igniters!

I've raised the PR [1] for the issue [2].
Could somebody review it?

Suggested implementation

If Ignite Security (IS) is enabled, then executors, accessed through the
PoolProcessor,
are wrapped to a security-aware implementation. Security-aware
implementation sets proper
security context for tasks that the executor performs.

The field subject id was deleted from communication requests for cache and
compute operations;
a remote node gets the subject id that initiates the ignite operation from
GridIoSecurityAwareMessage.
IgniteSecurity uses this id to set a proper security context during the
execution of the request.

Remove GridTaskThreadContextKey#TC_SUBJ_ID,
GridCacheContext#subjectIdPerCall;
a consumer has to obtain a current security subject id through
IgniteSecurity
or the set of SecurityUtils methods.

For all events that include the subject id field, are set the following
rule.
If IS is enabled, this field must contain a subject id that initiates
an ignite operation, otherwise null.

Implement SecurityAwareCustomMessageWrapper for discovery requests that act
as
GridIoSecurityAwareMessage for communication requests. It allows setting
proper
context during the discovery message execution.

Implement SecurityAwareGridRestCommandHandler to allow GridRestProcessor
to execute all client requests with the proper security context.

1. https://github.com/apache/ignite/pull/8038
2. https://issues.apache.org/jira/browse/IGNITE-13112

Re: Contributor grants request

[Andrey Gura]

Granted Contributor role. Feel free to assign issues.

On Tue, Apr 6, 2021 at 6:25 PM Smolnikov  wrote:
>
> My username is "Smolnikov"
>
>
>
> --
> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

[jira] [Created] (IGNITE-14493) Documents versions of Spring integration extensions.

[Mikhail Petrov (Jira)]

Mikhail Petrov created IGNITE-14493:
---

 Summary: Documents versions of Spring integration extensions.
 Key: IGNITE-14493
 URL: https://issues.apache.org/jira/browse/IGNITE-14493
 Project: Ignite
  Issue Type: Improvement
Reporter: Mikhail Petrov
Assignee: Mikhail Petrov


It's need to Documents available versions of Spring integration extensions.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Contributor grants request

[Smolnikov]

My username is "Smolnikov"



--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

Re: [DISCUSS] IEP-71 Public API for secondary index search

[Andrey Mashenkov]

Hi Maksim,

Nice idea, I'd like to see this feature in Ignite.
The motivation is clear to me, it would be nice to have fast scans and omit
SQL overhead on planning, parsing and etc in some simple use-cases.

I've left few minor comments to the IEP, but I have the next questions
which answer I failed to find in IEP.
1. Is it possible to extend ScanQuery functionality to pass index condition
as a hint/parameter rather than create a separate query type?
This allows a user to run a query over the particular table (for
multi-table per cache case) and use an index for some type of conditions.

2. Functional indices, as you wrote, should use Functions distributed via
peerClassLoading mechanics.
This means there will no class with function on server sides and such
classes are not persistent. Seems, they can survive grid restart.
This task looks like a huge one because the lifecycle of such classes
should be described first.
Possible pitfalls are:
* Durability. Function code MUST be persistent, to survive node restart as
there can be no guaranteed classes available on the server-side.
* Consistency. Server (and maybe clients) nodes MUST have the same class
code at a time.
* Code ownership. Would class code be shared or per-cache? If first, you
can't just change class code by loading a new one, because other caches may
use this function.
If second, different caches may have different code/behavior, that may be
non-obvious to end-user.

3. IndexScan by the predicate is questionable.
Maybe it will can faster if there are multiple tables in a cache, but looks
similar to ScanQuery with a filter.

Also, I believe we can have a common API (configuring, creating, using) for
all types of Indices, but
some types (e.g. functional) will be ignored in SQL due to limited support
on H2 side,
and other types will be shared and could be used by ScanQuery engine as
well as by SQL engine.

On Tue, Apr 6, 2021 at 4:14 PM Maksim Timonin 
wrote:

> Hi, Igniters!
>
> I'd like to propose a new feature - opportunity to query and create indexes
> from public API.
>
> It will help in some cases, where:
> 1. SQL is not applicable by design of user application;
> 2. Where IndexScan is preferable than ScanQuery for performance reasons;
> 3. Functional indexes are required.
>
> Also it'll be great to have a transactional support for such queries, like
> the "select for update" query provides. But I don't dig there much. It will
> be a next step if this API will be implemented.
>
> I've prepared an IEP-71 for that [1] with more details. Please share your
> thoughts.
>
>
> [1]
>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-71+Public+API+for+secondary+index+search
>


-- 
Best regards,
Andrey V. Mashenkov

Re: Contributor grants request

[Andrey Gura]

Hi, Rodion!

Could you please provide your Apache JIRA login name?

On Mon, Apr 5, 2021 at 5:37 PM Rodion Smolnikov  wrote:
>
> Hello!
> Can I get contributor access?
> Task https://issues.apache.org/jira/browse/IGNITE-14474
>
> --
>
> Rodion Smolnikov
>
> +7(915)256-54-81
> Software Developer, Russia
>
> *gridgain.com *

[jira] [Created] (IGNITE-14492) Java thin client: Refactor notification listener

[Aleksey Plekhanov (Jira)]

Aleksey Plekhanov created IGNITE-14492:
--

 Summary: Java thin client: Refactor notification listener 
 Key: IGNITE-14492
 URL: https://issues.apache.org/jira/browse/IGNITE-14492
 Project: Ignite
  Issue Type: Improvement
  Components: thin client
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
 Fix For: 2.11


To avoid iteration over all registered listeners, listeners should be 
registered for given notification type and resource ID.  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [DISCUSS] Query API for Ignite 3.0

[Andrey Mashenkov]

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  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: tled...@gridgain.com
>
>

-- 
Best regards,
Andrey V. Mashenkov

Re: [DISCUSS] Query API for Ignite 3.0

[Ivan Daschinsky]

>> The protocols are different a lot.
Оf course they are different. And handlersfers, because format different.
are different. But NIO server is the same. This is normal.
If you meant that it was probably possible to create one handler for JDBC
thin and ODBC, it would be probably possible.
But is there any profit from this?
>> May be we try to use JDBC as native query API?
So you suggests something like
```
Connection conn = ignite.getJdbcConnection();
Statement ps = connection.createStatement();
stmt.executeQuery();
```
and so on on thick clients?
As for me, jdbc is the most ugly thing I've ever seen. Current API is a way
better.

Do you think about some low level API that can be used to implement JDBC
thin/ ODBC/ thin client handlers, and thick client handlers also?
And over this protocol, it is possible to implement whatever you want.

>> R2DBC look like the popular and alive
Yes, it is great, as for me.




вт, 6 апр. 2021 г. в 15:58, Taras Ledkov :

> Hi, Ivan.
>
> My comments are inline.
>
> In general about JDBC native API:
> I see no reasons why a user must use different query APIs on the client
> and on the server node (e.g. inside services or jobs).
> It is complicate and not user-friendly.
>
>
> >>> 1.1. Thin JDBC client will be really thin: provide network
> communication
> > layer and transparently map to native API.
> > But we have already this in AI 2.x
> Not complete.
> JDBC thin is a implementation of the JDBC specification. But it uses
> Query API `query(SqlFieldsQuery)`.
> I see no reason to introduce new internal query API for 3.0 and wrap it
> into JDBC again.
> May be we try to use JDBC as native query API?
> This way doesn't prohibit to use any internal extension if need.
>
> >>> 1.2. Thick JDBC client implementation will be trivial: start client
> node
> > and open JDBC connection on the started node.
> > We have already this in AI 2.x and IMHO this functionality is weird and
> > need to be removed. No one wants to start new node from DBeaver :)
>
> I guess it will be removed on Ignite 2.x because implementation is weird
> (due to legacy).
>
>
> >>> 1.3 JDBC provides sufficient functionality to implement ODBC (need to
> > investigate: may be thin protocol may be extended to unify JDBC and
> ODBC).
> > We already have this in AI 2.x (JDBC and ODBC is mostly unified)
> It is absolutely wrong.
> ODBC, JDBC and thin client use the same port and unified head of the
> handshake message.
> The protocols are different a lot.
>
>
> On 06.04.2021 15:40, Ivan Daschinsky wrote:
> > Hi Taras!
> >>> 1.1. Thin JDBC client will be really thin: provide network
> communication
> > layer and transparently map to native API.
> > But we have already this in AI 2.x
> >>> 1.2. Thick JDBC client implementation will be trivial: start client
> node
> > and open JDBC connection on the started node.
> > We have already this in AI 2.x and IMHO this functionality is weird and
> > need to be removed. No one wants to start new node from DBeaver :)
> >>> 1.3 JDBC provides sufficient functionality to implement ODBC (need to
> > investigate: may be thin protocol may be extended to unify JDBC and
> ODBC).
> > We already have this in AI 2.x (JDBC and ODBC is mostly unified)
> >
> >
> > вт, 6 апр. 2021 г. в 15:05, Taras Ledkov :
> >
> >> 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
> >>
> 

[DISCUSS] IEP-71 Public API for secondary index search

[Maksim Timonin]

Hi, Igniters!

I'd like to propose a new feature - opportunity to query and create indexes
from public API.

It will help in some cases, where:
1. SQL is not applicable by design of user application;
2. Where IndexScan is preferable than ScanQuery for performance reasons;
3. Functional indexes are required.

Also it'll be great to have a transactional support for such queries, like
the "select for update" query provides. But I don't dig there much. It will
be a next step if this API will be implemented.

I've prepared an IEP-71 for that [1] with more details. Please share your
thoughts.


[1]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-71+Public+API+for+secondary+index+search

Re: [DISCUSS] Query API for Ignite 3.0

[Taras Ledkov]

Hi, Ivan.

My comments are inline.

In general about JDBC native API:
I see no reasons why a user must use different query APIs on the client 
and on the server node (e.g. inside services or jobs).

It is complicate and not user-friendly.



1.1. Thin JDBC client will be really thin: provide network communication

layer and transparently map to native API.
But we have already this in AI 2.x

Not complete.
JDBC thin is a implementation of the JDBC specification. But it uses 
Query API `query(SqlFieldsQuery)`.
I see no reason to introduce new internal query API for 3.0 and wrap it 
into JDBC again.

May be we try to use JDBC as native query API?
This way doesn't prohibit to use any internal extension if need.


1.2. Thick JDBC client implementation will be trivial: start client node

and open JDBC connection on the started node.
We have already this in AI 2.x and IMHO this functionality is weird and
need to be removed. No one wants to start new node from DBeaver :)


I guess it will be removed on Ignite 2.x because implementation is weird 
(due to legacy).




1.3 JDBC provides sufficient functionality to implement ODBC (need to

investigate: may be thin protocol may be extended to unify JDBC and ODBC).
We already have this in AI 2.x (JDBC and ODBC is mostly unified)

It is absolutely wrong.
ODBC, JDBC and thin client use the same port and unified head of the 
handshake message.

The protocols are different a lot.


On 06.04.2021 15:40, Ivan Daschinsky wrote:

Hi Taras!

1.1. Thin JDBC client will be really thin: provide network communication

layer and transparently map to native API.
But we have already this in AI 2.x

1.2. Thick JDBC client implementation will be trivial: start client node

and open JDBC connection on the started node.
We have already this in AI 2.x and IMHO this functionality is weird and
need to be removed. No one wants to start new node from DBeaver :)

1.3 JDBC provides sufficient functionality to implement ODBC (need to

investigate: may be thin protocol may be extended to unify JDBC and ODBC).
We already have this in AI 2.x (JDBC and ODBC is mostly unified)


вт, 6 апр. 2021 г. в 15:05, Taras Ledkov :


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: tled...@gridgain.com



--
Taras Ledkov
Mail-To: tled...@gridgain.com

Re: Permissions for creating page on Confluence

[Maksim Timonin]

Hi, Ilya!

It works, thanks a lot!

On Tue, Apr 6, 2021 at 3:48 PM Ilya Kasnacheev 
wrote:

> Hello!
>
> I have granted permissions to you. Please check.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> вт, 6 апр. 2021 г. в 15:33, Maksim Timonin :
>
> > Hi, Igniters!
> >
> > I'd like to propose a new IEP. Could smbd grant me write access on the
> > Confluence?
> >
> > My account is timonin.maksim.
> >
> > Thanks!
> >
>

Re: Permissions for creating page on Confluence

[Ilya Kasnacheev]

Hello!

I have granted permissions to you. Please check.

Regards,
-- 
Ilya Kasnacheev


вт, 6 апр. 2021 г. в 15:33, Maksim Timonin :

> Hi, Igniters!
>
> I'd like to propose a new IEP. Could smbd grant me write access on the
> Confluence?
>
> My account is timonin.maksim.
>
> Thanks!
>

Re: [DISCUSS] Query API for Ignite 3.0

[Ivan Daschinsky]

Hi Taras!
>> 1.1. Thin JDBC client will be really thin: provide network communication
layer and transparently map to native API.
But we have already this in AI 2.x
>> 1.2. Thick JDBC client implementation will be trivial: start client node
and open JDBC connection on the started node.
We have already this in AI 2.x and IMHO this functionality is weird and
need to be removed. No one wants to start new node from DBeaver :)
>> 1.3 JDBC provides sufficient functionality to implement ODBC (need to
investigate: may be thin protocol may be extended to unify JDBC and ODBC).
We already have this in AI 2.x (JDBC and ODBC is mostly unified)


вт, 6 апр. 2021 г. в 15:05, Taras Ledkov :

> 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: tled...@gridgain.com
>
>

-- 
Sincerely yours, Ivan Daschinskiy

Permissions for creating page on Confluence

[Maksim Timonin]

Hi, Igniters!

I'd like to propose a new IEP. Could smbd grant me write access on the
Confluence?

My account is timonin.maksim.

Thanks!

[jira] [Created] (IGNITE-14491) Docs on ThinClientKubernetesAddressFinder

[Nikita Safonov (Jira)]

Nikita Safonov created IGNITE-14491:
---

 Summary: Docs on ThinClientKubernetesAddressFinder
 Key: IGNITE-14491
 URL: https://issues.apache.org/jira/browse/IGNITE-14491
 Project: Ignite
  Issue Type: Improvement
  Components: documentation
Reporter: Nikita Safonov


{color:#00}ThinClientKubernetesAddressFinder is mentioned here:{color}
 
[https://ignite.apache.org/docs/latest/thin-clients/java-thin-client#partition-awareness

]- Please describe when to use it.

- See the relevant issue below:

_Check this section of the AWS EKS page: 
[https://ignite.apache.org/docs/latest/installation/kubernetes/amazon-eks-deployment#partition-awareness]_
  __  
 _The Partition Awareness is a top-level section and the "Connecting to REST 
API" is placed under it. Which is wrong. The Partition Awareness must be 
located as a sub-section of the "Connecting with Thin Clients" section that is 
above. If it's impossible to have another level under this tree then rename:_
 * _"Partition Awareness" -> "Connecting with Thin Clients and Partition 
Awareness"_

 
- This needs to be done for Azure and Google Pages as well.
 
Consult with dev team for more details.

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[DISCUSS] Query API for Ignite 3.0

[Taras Ledkov]

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: tled...@gridgain.com

Re: want to contribute to apache ignite

[Ilya Kasnacheev]

Hello!

I have added you to Contributors role. You may now assign tickets to
yourself.

Please make sure to read
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute

Regards,
-- 
Ilya Kasnacheev


вт, 6 апр. 2021 г. в 14:28, Sanjay Dash :

> Hi Team,
>
> I want to contribute to Aapache Ignite.Please give me permissions.
>
> As 3.0 is going to start,it will be a good starting point for me.
>
> username-sanjaykudash
>
> --
> regards
> sanjay
>

[jira] [Created] (IGNITE-14490) cache.invoke() triggers failure handler and freezes if entry processor is not urideployed

[Ilya Kasnacheev (Jira)]

Ilya Kasnacheev created IGNITE-14490:


 Summary: cache.invoke() triggers failure handler and freezes if 
entry processor is not urideployed
 Key: IGNITE-14490
 URL: https://issues.apache.org/jira/browse/IGNITE-14490
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.10
Reporter: Ilya Kasnacheev
Assignee: Ilya Kasnacheev


If URI deployment is specified

Caused by: java.lang.ClassNotFoundException: [Ljava.lang.StackTraceElement;"



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

want to contribute to apache ignite

[Sanjay Dash]

Hi Team,

I want to contribute to Aapache Ignite.Please give me permissions.

As 3.0 is going to start,it will be a good starting point for me.

username-sanjaykudash

-- 
regards
sanjay

[jira] [Created] (IGNITE-14489) Reduce wal operations if no update counters are changed.

[Stanilovsky Evgeny (Jira)]

Stanilovsky Evgeny created IGNITE-14489:
---

 Summary: Reduce wal operations if no update counters are changed.
 Key: IGNITE-14489
 URL: https://issues.apache.org/jira/browse/IGNITE-14489
 Project: Ignite
  Issue Type: Improvement
  Components: persistence
Affects Versions: 2.10
Reporter: Stanilovsky Evgeny
Assignee: Stanilovsky Evgeny


Reduce wal writes if update counters are not changed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-14488) Implement invoke operations for table views.

[Andrey Mashenkov (Jira)]

Andrey Mashenkov created IGNITE-14488:
-

 Summary: Implement invoke operations for table views.
 Key: IGNITE-14488
 URL: https://issues.apache.org/jira/browse/IGNITE-14488
 Project: Ignite
  Issue Type: Improvement
Reporter: Andrey Mashenkov
Assignee: Andrey Mashenkov


Implement Table binary projection API.
Extend existed tests to all table operations 
Example class is a good start point.




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-14487) Implement KeyValye binary view.

[Andrey Mashenkov (Jira)]

Andrey Mashenkov created IGNITE-14487:
-

 Summary: Implement KeyValye binary view.
 Key: IGNITE-14487
 URL: https://issues.apache.org/jira/browse/IGNITE-14487
 Project: Ignite
  Issue Type: Improvement
Reporter: Andrey Mashenkov
Assignee: Andrey Mashenkov


Implement Table binary projection API.
Extend existed tests to all table operations 
Example class is a good start point.




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-14486) Table binary view implementation.

[Andrey Mashenkov (Jira)]

Andrey Mashenkov created IGNITE-14486:
-

 Summary: Table binary view implementation.
 Key: IGNITE-14486
 URL: https://issues.apache.org/jira/browse/IGNITE-14486
 Project: Ignite
  Issue Type: Improvement
Reporter: Andrey Mashenkov
Assignee: Andrey Mashenkov
 Fix For: 3.0.0-alpha2


Implement KV and Table - binary projections over table.
Implement builders for binary objects\rows.

Add tests for all operations. Example class is a good start point.




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-14485) Docker execution fail on iptables change

[Anton Vinogradov (Jira)]

Anton Vinogradov created IGNITE-14485:
-

 Summary: Docker execution fail on iptables change
 Key: IGNITE-14485
 URL: https://issues.apache.org/jira/browse/IGNITE-14485
 Project: Ignite
  Issue Type: Bug
Reporter: Anton Vinogradov
Assignee: Vladimir Steshin


Fail example:
{noformat}
 [INFO:2021-04-06 12:21:56,650]: RunnerClient: 
0425dc@ignitetest.tests.discovery_test.DiscoveryTest.test_2_nodes_fail_sequential_zk.load_type=ClusterLoad.ATOMIC.ignite_version=2.10.0:
 FAIL: AssertionError("Command failed: 'sudo iptables -L -n'.\nError: '# 
Warning: iptables-legacy tables present, use iptables-legacy to see them\n'")
 Traceback (most recent call last):
 File "/usr/local/lib/python3.7/dist-packages/ducktape/tests/runner_client.py", 
line 133, in run
 data = self.run_test()
 File "/usr/local/lib/python3.7/dist-packages/ducktape/tests/runner_client.py", 
line 190, in run_test
 return self.test_context.function(self.test)
 File "/usr/local/lib/python3.7/dist-packages/ducktape/mark/_mark.py", line 
429, in wrapper
 return functools.partial(f, *args, **kwargs)(*w_args, **w_kwargs)
 File 
"/opt/ignite-dev/modules/ducktests/tests/ignitetest/tests/discovery_test.py", 
line 173, in test_2_nodes_fail_sequential_zk
 return self._perform_node_fail_scenario(test_config)
 File 
"/opt/ignite-dev/modules/ducktests/tests/ignitetest/tests/discovery_test.py", 
line 246, in _perform_node_fail_scenario
 test_config.net_part))
 File 
"/opt/ignite-dev/modules/ducktests/tests/ignitetest/tests/discovery_test.py", 
line 262, in _simulate_and_detect_failure
 _, first_terminated = servers.drop_network(failed_nodes, net_part=net_part)
 File 
"/opt/ignite-dev/modules/ducktests/tests/ignitetest/services/utils/ignite_aware.py",
 line 353, in drop_network
 self.__backup_iptables(nodes)
 File 
"/opt/ignite-dev/modules/ducktests/tests/ignitetest/services/utils/ignite_aware.py",
 line 414, in __backup_iptables
 self.logger.debug("Netfilter before launch on '%s': %s" % (node.name, 
self.__dump_netfilter_settings(node)))
 File 
"/opt/ignite-dev/modules/ducktests/tests/ignitetest/services/utils/ignite_aware.py",
 line 451, in __dump_netfilter_settings
 return IgniteAwareService.exec_command(node, "sudo iptables -L -n")
 File 
"/opt/ignite-dev/modules/ducktests/tests/ignitetest/services/utils/ignite_aware.py",
 line 481, in exec_command
 assert len(err) == 0, f"Command failed: '\{cmd}'.\nError: '\{err}'"
 AssertionError: Command failed: 'sudo iptables -L -n'.
 Error: '# Warning: iptables-legacy tables present, use iptables-legacy to see 
them
 '
 {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-14484) Implement RecordView API.

[Andrey Mashenkov (Jira)]

Andrey Mashenkov created IGNITE-14484:
-

 Summary: Implement RecordView API.
 Key: IGNITE-14484
 URL: https://issues.apache.org/jira/browse/IGNITE-14484
 Project: Ignite
  Issue Type: Improvement
Reporter: Andrey Mashenkov
Assignee: Alexander Belyak


Implement user-class mappers for key-value view and record view and add custom 
mapper support to marshallers initially implemented in IGNITE-13618.

Supposed, mappers are used for schema generation from user-classes (annotation 
schema configuration) and schema validation.
Mappers might be highly coupled with marshallers\serislizers (especially 
generated marshaller).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-14483) Ignite_app and ignite clean_up

[Anton Vinogradov (Jira)]

Anton Vinogradov created IGNITE-14483:
-

 Summary: Ignite_app and ignite clean_up
 Key: IGNITE-14483
 URL: https://issues.apache.org/jira/browse/IGNITE-14483
 Project: Ignite
  Issue Type: Sub-task
Reporter: Anton Vinogradov
Assignee: Anton Vinogradov


Clean up and simplify.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)