[jira] [Updated] (IGNITE-21743) .NET: LINQ: Cast to decimal loses precision
[ https://issues.apache.org/jira/browse/IGNITE-21743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-21743: Priority: Minor (was: Major) > .NET: LINQ: Cast to decimal loses precision > --- > > Key: IGNITE-21743 > URL: https://issues.apache.org/jira/browse/IGNITE-21743 > Project: Ignite > Issue Type: Bug > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Minor > Labels: .NET, LINQ, ignite-3 > Fix For: 3.0.0-beta2 > > > Currently we use *as decimal* cast, which results in *scale=0*, truncating > any digits after the decimal point. > See ticket mention in *IgniteQueryExpressionVisitor* - we should specify > scale and precision when performing cast to decimal. > Blocked by IGNITE-21745 : .NET can't read small values with high scale. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22048) .NET: Thin 3.0: Add Gradle task to run tests
[ https://issues.apache.org/jira/browse/IGNITE-22048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22048: Priority: Trivial (was: Major) > .NET: Thin 3.0: Add Gradle task to run tests > > > Key: IGNITE-22048 > URL: https://issues.apache.org/jira/browse/IGNITE-22048 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Trivial > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > > Add a Gradle task to run .NET tests. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22049) C++: Thin 3.0: Add Gradle task to run tests
[ https://issues.apache.org/jira/browse/IGNITE-22049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22049: Priority: Trivial (was: Major) > C++: Thin 3.0: Add Gradle task to run tests > --- > > Key: IGNITE-22049 > URL: https://issues.apache.org/jira/browse/IGNITE-22049 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Igor Sapego >Priority: Trivial > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Add a Gradle task to run C++ tests. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22090) Thin 3.0: Avoid TX_BEGIN round-trip
[
https://issues.apache.org/jira/browse/IGNITE-22090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-22090:
Epic Link: IGNITE-19479
> Thin 3.0: Avoid TX_BEGIN round-trip
> ---
>
> Key: IGNITE-22090
> URL: https://issues.apache.org/jira/browse/IGNITE-22090
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> IGNITE-19681 implements tx partition awareness, where TX_BEGIN request is
> performed together with the first enlisted operation. However, this still
> involves a separate round-trip to start the transaction.
> We can change the protocol to do two things in one go:
> * Start the transaction
> * Enlist first operation
> See the comment from [~ascherbakov]:
> https://github.com/apache/ignite-3/pull/3640#discussion_r1575943518
> {code}
> This can be optimized even further.
> Currently we still have +1RTT due to begin tx request/response here, which
> may be sensitive to small transactions.
> A transaction should be started on first map request.
> For this to work logical client tx id should be assigned on client.
> For example, id can consist of local client counter combined with client
> unique id assigned by server on handshake.
> One bit of 64 bit id is reserved for "first" flag.
> If an operation is "first", the txn is implicitly started.
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20475) .NET: Thin 3.0: EF Core provider (investigate)
[ https://issues.apache.org/jira/browse/IGNITE-20475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17841849#comment-17841849 ] Pavel Tupitsyn commented on IGNITE-20475: - Investigation complete, working PoC created: https://github.com/apache/ignite-3/pull/3675 *Conclusion* Implementing an EF Core provider is feasible and we should do that. *Proposed Work Plan* See IGNITE-22132: 1. Implement ADO.NET classes (connection, command, etc): IGNITE-22131 2. Polish the PoC implementation to create a basic provider: IGNITE-22133 3. Add specification tests, create tickets for missing/failing things: IGNITE-22134 4. Add NuGet package once we have most of the tests working > .NET: Thin 3.0: EF Core provider (investigate) > -- > > Key: IGNITE-20475 > URL: https://issues.apache.org/jira/browse/IGNITE-20475 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > EF Core provider will allow using Ignite as any other DB supported by EF. > This makes adoption incredibly easy for the users - a matter of a few changed > lines to switch from Postgres/MsSQL/MySQL, keeping all existing code. > This is also a big undertaking and needs more investigation/PoC. > * https://learn.microsoft.com/en-us/ef/core/providers/writing-a-provider > * > https://blog.oneunicorn.com/2016/11/11/so-you-want-to-write-an-ef-core-provider/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-20475) .NET: Thin 3.0: EF Core provider (investigate)
[ https://issues.apache.org/jira/browse/IGNITE-20475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17841849#comment-17841849 ] Pavel Tupitsyn edited comment on IGNITE-20475 at 4/29/24 5:44 AM: -- Investigation complete, working PoC created: https://github.com/apache/ignite-3/pull/3675 *Conclusion* Implementing an EF Core provider is feasible and we should do that. *Proposed Work Plan* See IGNITE-22132: 1. Implement ADO.NET classes (connection, command, etc): IGNITE-22131 2. Polish the PoC implementation to create a basic provider: IGNITE-22133 3. Add specification tests, create tickets for missing/failing things: IGNITE-22134 4. Add NuGet package once we have most of the tests working was (Author: ptupitsyn): Investigation complete, working PoC created: https://github.com/apache/ignite-3/pull/3675 *Conclusion* Implementing an EF Core provider is feasible and we should do that. *Proposed Work Plan* See IGNITE-22132: 1. Implement ADO.NET classes (connection, command, etc): IGNITE-22131 2. Polish the PoC implementation to create a basic provider: IGNITE-22133 3. Add specification tests, create tickets for missing/failing things: IGNITE-22134 4. Add NuGet package once we have most of the tests working > .NET: Thin 3.0: EF Core provider (investigate) > -- > > Key: IGNITE-20475 > URL: https://issues.apache.org/jira/browse/IGNITE-20475 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > EF Core provider will allow using Ignite as any other DB supported by EF. > This makes adoption incredibly easy for the users - a matter of a few changed > lines to switch from Postgres/MsSQL/MySQL, keeping all existing code. > This is also a big undertaking and needs more investigation/PoC. > * https://learn.microsoft.com/en-us/ef/core/providers/writing-a-provider > * > https://blog.oneunicorn.com/2016/11/11/so-you-want-to-write-an-ef-core-provider/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22134) .NET: Thin 3.0: Specification tests for EF Core provider
[ https://issues.apache.org/jira/browse/IGNITE-22134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22134: Ignite Flags: (was: Docs Required,Release Notes Required) > .NET: Thin 3.0: Specification tests for EF Core provider > > > Key: IGNITE-22134 > URL: https://issues.apache.org/jira/browse/IGNITE-22134 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > > Add EF Core specification tests > https://learn.microsoft.com/en-us/ef/core/providers/writing-a-provider#the-ef-core-specification-tests > Many of them will fail - disable and create tickets within IGNITE-22132 epic. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22134) .NET: Thin 3.0: Specification tests for EF Core provider
[ https://issues.apache.org/jira/browse/IGNITE-22134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22134: Description: Add EF Core specification tests https://learn.microsoft.com/en-us/ef/core/providers/writing-a-provider#the-ef-core-specification-tests Many of them will fail - disable and create tickets within IGNITE-22132 epic. was:Implement bare bones EF Core provider using the working POC from IGNITE-20475 and ADO.NET classes from IGNITE-22131. > .NET: Thin 3.0: Specification tests for EF Core provider > > > Key: IGNITE-22134 > URL: https://issues.apache.org/jira/browse/IGNITE-22134 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > > Add EF Core specification tests > https://learn.microsoft.com/en-us/ef/core/providers/writing-a-provider#the-ef-core-specification-tests > Many of them will fail - disable and create tickets within IGNITE-22132 epic. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22134) .NET: Thin 3.0: Specification tests for EF Core provider
Pavel Tupitsyn created IGNITE-22134: --- Summary: .NET: Thin 3.0: Specification tests for EF Core provider Key: IGNITE-22134 URL: https://issues.apache.org/jira/browse/IGNITE-22134 Project: Ignite Issue Type: New Feature Components: platforms, thin client Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Implement bare bones EF Core provider using the working POC from IGNITE-20475 and ADO.NET classes from IGNITE-22131. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22133) .NET: Thin 3.0: Basic EF Core provider
[ https://issues.apache.org/jira/browse/IGNITE-22133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22133: Description: Implement bare bones EF Core provider using the working POC from IGNITE-20475 and ADO.NET classes from IGNITE-22131. (was: We already have *IgniteDbDataReader* (IGNITE-18478), let's add other essential classes to enable integrations with higher-level frameworks (e.g. EF Core - IGNITE-20475): * DbConnection * DbCommand * DbParameter * DbParameterCollection * DbTransaction https://learn.microsoft.com/en-us/dotnet/framework/data/adonet/ado-net-overview) > .NET: Thin 3.0: Basic EF Core provider > -- > > Key: IGNITE-22133 > URL: https://issues.apache.org/jira/browse/IGNITE-22133 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > > Implement bare bones EF Core provider using the working POC from IGNITE-20475 > and ADO.NET classes from IGNITE-22131. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22133) .NET: Thin 3.0: Basic EF Core provider
Pavel Tupitsyn created IGNITE-22133: --- Summary: .NET: Thin 3.0: Basic EF Core provider Key: IGNITE-22133 URL: https://issues.apache.org/jira/browse/IGNITE-22133 Project: Ignite Issue Type: New Feature Components: platforms, thin client Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn We already have *IgniteDbDataReader* (IGNITE-18478), let's add other essential classes to enable integrations with higher-level frameworks (e.g. EF Core - IGNITE-20475): * DbConnection * DbCommand * DbParameter * DbParameterCollection * DbTransaction https://learn.microsoft.com/en-us/dotnet/framework/data/adonet/ado-net-overview -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20475) .NET: Thin 3.0: EF Core provider (investigate)
[ https://issues.apache.org/jira/browse/IGNITE-20475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20475: Epic Link: IGNITE-22132 > .NET: Thin 3.0: EF Core provider (investigate) > -- > > Key: IGNITE-20475 > URL: https://issues.apache.org/jira/browse/IGNITE-20475 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > EF Core provider will allow using Ignite as any other DB supported by EF. > This makes adoption incredibly easy for the users - a matter of a few changed > lines to switch from Postgres/MsSQL/MySQL, keeping all existing code. > This is also a big undertaking and needs more investigation/PoC. > * https://learn.microsoft.com/en-us/ef/core/providers/writing-a-provider > * > https://blog.oneunicorn.com/2016/11/11/so-you-want-to-write-an-ef-core-provider/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22131) .NET: Thin 3.0: Implement essential ADO.NET classes
[ https://issues.apache.org/jira/browse/IGNITE-22131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22131: Epic Link: IGNITE-22132 > .NET: Thin 3.0: Implement essential ADO.NET classes > --- > > Key: IGNITE-22131 > URL: https://issues.apache.org/jira/browse/IGNITE-22131 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > > We already have *IgniteDbDataReader* (IGNITE-18478), let's add other > essential classes to enable integrations with higher-level frameworks (e.g. > EF Core - IGNITE-20475): > * DbConnection > * DbCommand > * DbParameter > * DbParameterCollection > * DbTransaction > https://learn.microsoft.com/en-us/dotnet/framework/data/adonet/ado-net-overview -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22132) .NET: Thin 3.0: EF Core provider
[ https://issues.apache.org/jira/browse/IGNITE-22132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22132: Description: EF Core provider will allow using Ignite as any other DB supported by EF. This makes adoption incredibly easy for the users - a matter of a few changed lines to switch from Postgres/MsSQL/MySQL, keeping all existing code. h2. But we already have a LINQ provider, what is the difference? Think micro-ORM vs full-blown one. *Ignite LINQ provider:* * Comes in the box, very lightweight * Can do LINQ without any setup, literally one line * Limited DML * No DDL *EF Core:* * Separate package * Full-blown ORM, extremely powerful * Familiar to any .NET developer, same API for many databases h2. More Info * EF Core is the most popular ORM for .NET. Provides an abstract way of working with a database without writing any SQL by hand. Includes DDL, DML, migrations. * Providers exist for many databases: https://learn.microsoft.com/en-us/ef/core/providers/ * Writing a provider: https://learn.microsoft.com/en-us/ef/core/providers/writing-a-provider * Reference implementation: https://github.com/dotnet/efcore/tree/main/src/EFCore.Sqlite.Core > .NET: Thin 3.0: EF Core provider > > > Key: IGNITE-22132 > URL: https://issues.apache.org/jira/browse/IGNITE-22132 > Project: Ignite > Issue Type: Epic > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > > EF Core provider will allow using Ignite as any other DB supported by EF. > This makes adoption incredibly easy for the users - a matter of a few changed > lines to switch from Postgres/MsSQL/MySQL, keeping all existing code. > h2. But we already have a LINQ provider, what is the difference? > Think micro-ORM vs full-blown one. > *Ignite LINQ provider:* > * Comes in the box, very lightweight > * Can do LINQ without any setup, literally one line > * Limited DML > * No DDL > *EF Core:* > * Separate package > * Full-blown ORM, extremely powerful > * Familiar to any .NET developer, same API for many databases > h2. More Info > * EF Core is the most popular ORM for .NET. Provides an abstract way of > working with a database without writing any SQL by hand. Includes DDL, DML, > migrations. > * Providers exist for many databases: > https://learn.microsoft.com/en-us/ef/core/providers/ > * Writing a provider: > https://learn.microsoft.com/en-us/ef/core/providers/writing-a-provider > * Reference implementation: > https://github.com/dotnet/efcore/tree/main/src/EFCore.Sqlite.Core -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22132) .NET: Thin 3.0: EF Core provider
Pavel Tupitsyn created IGNITE-22132: --- Summary: .NET: Thin 3.0: EF Core provider Key: IGNITE-22132 URL: https://issues.apache.org/jira/browse/IGNITE-22132 Project: Ignite Issue Type: Epic Components: platforms, thin client Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22131) .NET: Thin 3.0: Implement essential ADO.NET classes
[ https://issues.apache.org/jira/browse/IGNITE-22131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22131: Description: We already have *IgniteDbDataReader* (IGNITE-18478), let's add other essential classes to enable integrations with higher-level frameworks (e.g. EF Core - IGNITE-20475): * DbConnection * DbCommand * DbParameter * DbParameterCollection * DbTransaction https://learn.microsoft.com/en-us/dotnet/framework/data/adonet/ado-net-overview was: We already have *IgniteDbDataReader* (IGNITE-18478), let's add other essential classes to enable integrations with higher-level frameworks (e.g. EF Core - IGNITE-20475): * DbConnection * DbCommand * DbParameter * DbParameterCollection * DbTransaction > .NET: Thin 3.0: Implement essential ADO.NET classes > --- > > Key: IGNITE-22131 > URL: https://issues.apache.org/jira/browse/IGNITE-22131 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > > We already have *IgniteDbDataReader* (IGNITE-18478), let's add other > essential classes to enable integrations with higher-level frameworks (e.g. > EF Core - IGNITE-20475): > * DbConnection > * DbCommand > * DbParameter > * DbParameterCollection > * DbTransaction > https://learn.microsoft.com/en-us/dotnet/framework/data/adonet/ado-net-overview -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22131) .NET: Thin 3.0: Implement essential ADO.NET classes
[ https://issues.apache.org/jira/browse/IGNITE-22131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22131: Description: We already have *IgniteDbDataReader* (IGNITE-18478), let's add other essential classes to enable integrations with higher-level frameworks (e.g. EF Core - IGNITE-20475): * > .NET: Thin 3.0: Implement essential ADO.NET classes > --- > > Key: IGNITE-22131 > URL: https://issues.apache.org/jira/browse/IGNITE-22131 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > > We already have *IgniteDbDataReader* (IGNITE-18478), let's add other > essential classes to enable integrations with higher-level frameworks (e.g. > EF Core - IGNITE-20475): > * -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22131) .NET: Thin 3.0: Implement essential ADO.NET classes
[ https://issues.apache.org/jira/browse/IGNITE-22131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22131: Description: We already have *IgniteDbDataReader* (IGNITE-18478), let's add other essential classes to enable integrations with higher-level frameworks (e.g. EF Core - IGNITE-20475): * DbConnection * DbCommand * DbParameter * DbParameterCollection * DbTransaction was: We already have *IgniteDbDataReader* (IGNITE-18478), let's add other essential classes to enable integrations with higher-level frameworks (e.g. EF Core - IGNITE-20475): * > .NET: Thin 3.0: Implement essential ADO.NET classes > --- > > Key: IGNITE-22131 > URL: https://issues.apache.org/jira/browse/IGNITE-22131 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > > We already have *IgniteDbDataReader* (IGNITE-18478), let's add other > essential classes to enable integrations with higher-level frameworks (e.g. > EF Core - IGNITE-20475): > * DbConnection > * DbCommand > * DbParameter > * DbParameterCollection > * DbTransaction -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22131) .NET: Thin 3.0: Implement essential ADO.NET classes
Pavel Tupitsyn created IGNITE-22131: --- Summary: .NET: Thin 3.0: Implement essential ADO.NET classes Key: IGNITE-22131 URL: https://issues.apache.org/jira/browse/IGNITE-22131 Project: Ignite Issue Type: New Feature Components: platforms, thin client Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19681) Thin 3.0: Tx partition awareness
[ https://issues.apache.org/jira/browse/IGNITE-19681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840063#comment-17840063 ] Pavel Tupitsyn commented on IGNITE-19681: - Merged to main: 6dedb616b32f950da2020330a913ce7a8d292017 > Thin 3.0: Tx partition awareness > > > Key: IGNITE-19681 > URL: https://issues.apache.org/jira/browse/IGNITE-19681 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Currently, client sends a separate *TX_BEGIN* request when the user invokes > *IgniteTransactions.begin()* API: > * Extra network request. > * Chosen tx coordinator (server node that handles TX_BEGIN request) is random > and in most cases won't be the primary node for enlisted keys. > Solution: > * On the client, do not send *TX_BEGIN* request when the user invokes > *IgniteTransactions.begin()*. Instead, start the tx "on demand" when it is > first used in some API. > * Send two requests at once to the same node where the first enlisted > operation goes (according to partition awareness, if applicable). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22090) Thin 3.0: Avoid TX_BEGIN round-trip
[
https://issues.apache.org/jira/browse/IGNITE-22090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-22090:
Description:
IGNITE-19681 implements tx partition awareness, where TX_BEGIN request is
performed together with the first enlisted operation. However, this still
involves a separate round-trip to start the transaction.
We can change the protocol to do two things in one go:
* Start the transaction
* Enlist first operation
See the comment from [~ascherbakov]:
https://github.com/apache/ignite-3/pull/3640#discussion_r1575943518
{code}
This can be optimized even further.
Currently we still have +1RTT due to begin tx request/response here, which may
be sensitive to small transactions.
A transaction should be started on first map request.
For this to work logical client tx id should be assigned on client.
For example, id can consist of local client counter combined with client unique
id assigned by server on handshake.
One bit of 64 bit id is reserved for "first" flag.
If an operation is "first", the txn is implicitly started.
{code}
was:
IGNITE-19681 implements tx partition awareness, where TX_BEGIN request is
performed together with the first enlisted operation. However, this still
involves a separate round-trip to start the transaction.
We can change the protocol to do two things in one go:
* Start the transaction
* Enlist first operation
See the comment from [~ascherbakov]:
https://github.com/apache/ignite-3/pull/3640#discussion_r1575943518
> Thin 3.0: Avoid TX_BEGIN round-trip
> ---
>
> Key: IGNITE-22090
> URL: https://issues.apache.org/jira/browse/IGNITE-22090
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> IGNITE-19681 implements tx partition awareness, where TX_BEGIN request is
> performed together with the first enlisted operation. However, this still
> involves a separate round-trip to start the transaction.
> We can change the protocol to do two things in one go:
> * Start the transaction
> * Enlist first operation
> See the comment from [~ascherbakov]:
> https://github.com/apache/ignite-3/pull/3640#discussion_r1575943518
> {code}
> This can be optimized even further.
> Currently we still have +1RTT due to begin tx request/response here, which
> may be sensitive to small transactions.
> A transaction should be started on first map request.
> For this to work logical client tx id should be assigned on client.
> For example, id can consist of local client counter combined with client
> unique id assigned by server on handshake.
> One bit of 64 bit id is reserved for "first" flag.
> If an operation is "first", the txn is implicitly started.
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22090) Thin 3.0: Avoid TX_BEGIN round-trip
[ https://issues.apache.org/jira/browse/IGNITE-22090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22090: Description: IGNITE-19681 implements tx partition awareness, where TX_BEGIN request is performed together with the first enlisted operation. However, this still involves a separate round-trip to start the transaction. We can change the protocol to do two things in one go: * Start the transaction * Enlist first operation See the comment from [~ascherbakov]: https://github.com/apache/ignite-3/pull/3640#discussion_r1575943518 was: IGNITE-19681 implements tx partition awareness, where TX_BEGIN request is performed together with the first enlisted operation. However, this still involves a separate round-trip to start the transaction. We can change the protocol to do two things in one go: * Start the transaction * Enlist first operation > Thin 3.0: Avoid TX_BEGIN round-trip > --- > > Key: IGNITE-22090 > URL: https://issues.apache.org/jira/browse/IGNITE-22090 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > IGNITE-19681 implements tx partition awareness, where TX_BEGIN request is > performed together with the first enlisted operation. However, this still > involves a separate round-trip to start the transaction. > We can change the protocol to do two things in one go: > * Start the transaction > * Enlist first operation > See the comment from [~ascherbakov]: > https://github.com/apache/ignite-3/pull/3640#discussion_r1575943518 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22090) Thin 3.0: Avoid TX_BEGIN round-trip
[ https://issues.apache.org/jira/browse/IGNITE-22090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22090: Description: IGNITE-19681 implements tx partition awareness, where TX_BEGIN request is performed together with the first enlisted operation. However, this still involves a separate round-trip to start the transaction. We can change the protocol to do two things in one go: * Start the transaction * Enlist first operation > Thin 3.0: Avoid TX_BEGIN round-trip > --- > > Key: IGNITE-22090 > URL: https://issues.apache.org/jira/browse/IGNITE-22090 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > IGNITE-19681 implements tx partition awareness, where TX_BEGIN request is > performed together with the first enlisted operation. However, this still > involves a separate round-trip to start the transaction. > We can change the protocol to do two things in one go: > * Start the transaction > * Enlist first operation -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22090) Thin 3.0: Avoid TX_BEGIN round-trip
Pavel Tupitsyn created IGNITE-22090: --- Summary: Thin 3.0: Avoid TX_BEGIN round-trip Key: IGNITE-22090 URL: https://issues.apache.org/jira/browse/IGNITE-22090 Project: Ignite Issue Type: Improvement Components: thin client Affects Versions: 3.0.0-beta1 Reporter: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19684) С++: Thin 3.0: Tx partition awareness
[ https://issues.apache.org/jira/browse/IGNITE-19684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-19684: Summary: С++: Thin 3.0: Tx partition awareness (was: С++: Thin 3.0: Combine tx.begin with first enlisted operation) > С++: Thin 3.0: Tx partition awareness > - > > Key: IGNITE-19684 > URL: https://issues.apache.org/jira/browse/IGNITE-19684 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Igor Sapego >Priority: Major > Labels: C++, ignite-3 > Fix For: 3.0.0-beta2 > > > Currently, client sends a separate *TX_BEGIN* request when the user invokes > *transactions.begin_async()* API: > * Extra network request. > * Chosen tx coordinator (server node that handles TX_BEGIN request) is random > and in most cases won't be the primary node for enlisted keys. > Solution: > * On the client, do not send *TX_BEGIN* request when the user invokes > *transactions.begin_async()*. Instead, start the tx "on demand" when it is > first used in some API. > * Send two requests at once to the same node where the first enlisted > operation goes (according to partition awareness, if applicable). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19682) .NET: Thin 3.0: Tx partition awareness
[ https://issues.apache.org/jira/browse/IGNITE-19682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-19682: Summary: .NET: Thin 3.0: Tx partition awareness (was: .NET: Thin 3.0: Combine tx.begin with first enlisted operation) > .NET: Thin 3.0: Tx partition awareness > -- > > Key: IGNITE-19682 > URL: https://issues.apache.org/jira/browse/IGNITE-19682 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3, performance > Fix For: 3.0.0-beta2 > > > Currently, client sends a separate *TX_BEGIN* request when the user invokes > *ITransactions.BeginAsync* API: > * Extra network request. > * Chosen tx coordinator (server node that handles TX_BEGIN request) is random > and in most cases won't be the primary node for enlisted keys. > Solution: > * On the client, do not send *TX_BEGIN* request when the user invokes > *ITransactions.BeginAsync*. Instead, start the tx "on demand" when it is > first used in some API. > * Send two requests at once to the same node where the first enlisted > operation goes (according to partition awareness, if applicable). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19681) Thin 3.0: Tx partition awareness
[ https://issues.apache.org/jira/browse/IGNITE-19681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-19681: Summary: Thin 3.0: Tx partition awareness (was: Thin 3.0: Combine tx.begin with first enlisted operation) > Thin 3.0: Tx partition awareness > > > Key: IGNITE-19681 > URL: https://issues.apache.org/jira/browse/IGNITE-19681 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Currently, client sends a separate *TX_BEGIN* request when the user invokes > *IgniteTransactions.begin()* API: > * Extra network request. > * Chosen tx coordinator (server node that handles TX_BEGIN request) is random > and in most cases won't be the primary node for enlisted keys. > Solution: > * On the client, do not send *TX_BEGIN* request when the user invokes > *IgniteTransactions.begin()*. Instead, start the tx "on demand" when it is > first used in some API. > * Send two requests at once to the same node where the first enlisted > operation goes (according to partition awareness, if applicable). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20475) .NET: Thin 3.0: EF Core provider (investigate)
[ https://issues.apache.org/jira/browse/IGNITE-20475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20475: Description: EF Core provider will allow using Ignite as any other DB supported by EF. This makes adoption incredibly easy for the users - a matter of a few changed lines to switch from Postgres/MsSQL/MySQL, keeping all existing code. This is also a big undertaking and needs more investigation/PoC. * https://learn.microsoft.com/en-us/ef/core/providers/writing-a-provider * https://blog.oneunicorn.com/2016/11/11/so-you-want-to-write-an-ef-core-provider/ was: EF Core provider will allow using Ignite as any other DB supported by EF. This makes adoption incredibly easy for the users - a matter of a few changed lines to switch from Postgres/MsSQL/MySQL, keeping all existing code. This is also a big undertaking and needs more investigation/PoC. > .NET: Thin 3.0: EF Core provider (investigate) > -- > > Key: IGNITE-20475 > URL: https://issues.apache.org/jira/browse/IGNITE-20475 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > > EF Core provider will allow using Ignite as any other DB supported by EF. > This makes adoption incredibly easy for the users - a matter of a few changed > lines to switch from Postgres/MsSQL/MySQL, keeping all existing code. > This is also a big undertaking and needs more investigation/PoC. > * https://learn.microsoft.com/en-us/ef/core/providers/writing-a-provider > * > https://blog.oneunicorn.com/2016/11/11/so-you-want-to-write-an-ef-core-provider/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20475) .NET: Thin 3.0: EF Core provider (investigate)
[ https://issues.apache.org/jira/browse/IGNITE-20475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20475: Summary: .NET: Thin 3.0: EF Core provider (investigate) (was: .NET: Thin 3.0: EF Core provider) > .NET: Thin 3.0: EF Core provider (investigate) > -- > > Key: IGNITE-20475 > URL: https://issues.apache.org/jira/browse/IGNITE-20475 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > > EF Core provider will allow using Ignite as any other DB supported by EF. > This makes adoption incredibly easy for the users - a matter of a few changed > lines to switch from Postgres/MsSQL/MySQL, keeping all existing code. > This is also a big undertaking and needs more investigation/PoC. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22068) Inconsistent SQL and Criteria API behaviour
[ https://issues.apache.org/jira/browse/IGNITE-22068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839576#comment-17839576 ] Pavel Tupitsyn commented on IGNITE-22068: - Might be caused by IGNITE-22086, let's double check after the fix. > Inconsistent SQL and Criteria API behaviour > --- > > Key: IGNITE-22068 > URL: https://issues.apache.org/jira/browse/IGNITE-22068 > Project: Ignite > Issue Type: Bug > Components: sql, thin client >Reporter: Vadim Pakhnushev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Attachments: CountTest-1.java > > > When running a query through thin client Criteria API and SQL API the results > are sometimes differs with the same client. > Reproducer is attached. > For some reason, the test only fails at the second repetition. > Leaving only the countCriteria line and comparing it with the recordCount > doesn't fail the test. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22068) Inconsistent SQL and Criteria API behaviour
[ https://issues.apache.org/jira/browse/IGNITE-22068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22068: Summary: Inconsistent SQL and Criteria API behaviour (was: Inconsistent API behaviour) > Inconsistent SQL and Criteria API behaviour > --- > > Key: IGNITE-22068 > URL: https://issues.apache.org/jira/browse/IGNITE-22068 > Project: Ignite > Issue Type: Bug > Components: sql, thin client >Reporter: Vadim Pakhnushev >Priority: Major > Labels: ignite-3 > Attachments: CountTest-1.java > > > When running a query through thin client Criteria API and SQL API the results > are sometimes differs with the same client. > Reproducer is attached. > For some reason, the test only fails at the second repetition. > Leaving only the countCriteria line and comparing it with the recordCount > doesn't fail the test. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22068) Inconsistent SQL and Criteria API behaviour
[ https://issues.apache.org/jira/browse/IGNITE-22068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22068: Fix Version/s: 3.0.0-beta2 > Inconsistent SQL and Criteria API behaviour > --- > > Key: IGNITE-22068 > URL: https://issues.apache.org/jira/browse/IGNITE-22068 > Project: Ignite > Issue Type: Bug > Components: sql, thin client >Reporter: Vadim Pakhnushev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Attachments: CountTest-1.java > > > When running a query through thin client Criteria API and SQL API the results > are sometimes differs with the same client. > Reproducer is attached. > For some reason, the test only fails at the second repetition. > Leaving only the countCriteria line and comparing it with the recordCount > doesn't fail the test. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22086) Thin 3.0: observableTimestamp is 0 after handshake
[ https://issues.apache.org/jira/browse/IGNITE-22086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-22086: --- Assignee: Pavel Tupitsyn > Thin 3.0: observableTimestamp is 0 after handshake > -- > > Key: IGNITE-22086 > URL: https://issues.apache.org/jira/browse/IGNITE-22086 > Project: Ignite > Issue Type: Bug > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > We propagate *observableTimestamp* to client with every response (see > *ClientInboundMessageHandler#writeResponseHeader*), but not on handshake. As > a result, the very first operation from the client has > *observableTimestamp=0*, which can lead to causality issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22086) Thin 3.0: observableTimestamp is 0 after handshake
[ https://issues.apache.org/jira/browse/IGNITE-22086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22086: Description: We propagate *observableTimestamp* to client with every response (see *ClientInboundMessageHandler#writeResponseHeader*), but not on handshake. As a result, the very first operation from the client has *observableTimestamp=0*, which can lead to causality issues. (was: We propagate *observableTimestamp* to client with every response (see *ClientInboundMessageHandler#writeResponseHeader*), but not on handshake. As a result, the very first operation from the client has *observableTimestamp=0*, which can cause causality issues.) > Thin 3.0: observableTimestamp is 0 after handshake > -- > > Key: IGNITE-22086 > URL: https://issues.apache.org/jira/browse/IGNITE-22086 > Project: Ignite > Issue Type: Bug > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > We propagate *observableTimestamp* to client with every response (see > *ClientInboundMessageHandler#writeResponseHeader*), but not on handshake. As > a result, the very first operation from the client has > *observableTimestamp=0*, which can lead to causality issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22086) Thin 3.0: observableTimestamp is 0 after handshake
[ https://issues.apache.org/jira/browse/IGNITE-22086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22086: Description: We propagate *observableTimestamp* to client with every response (see *ClientInboundMessageHandler#writeResponseHeader*), but not on handshake. As a result, the very first operation from the client has *observableTimestamp=0*, which can cause causality issues. > Thin 3.0: observableTimestamp is 0 after handshake > -- > > Key: IGNITE-22086 > URL: https://issues.apache.org/jira/browse/IGNITE-22086 > Project: Ignite > Issue Type: Bug > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > We propagate *observableTimestamp* to client with every response (see > *ClientInboundMessageHandler#writeResponseHeader*), but not on handshake. As > a result, the very first operation from the client has > *observableTimestamp=0*, which can cause causality issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22086) Thin 3.0: observableTimestamp is 0 after handshake
Pavel Tupitsyn created IGNITE-22086: --- Summary: Thin 3.0: observableTimestamp is 0 after handshake Key: IGNITE-22086 URL: https://issues.apache.org/jira/browse/IGNITE-22086 Project: Ignite Issue Type: Bug Components: platforms, thin client Reporter: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22052) С++ 3.0: basic_authenticator_test is flaky
[ https://issues.apache.org/jira/browse/IGNITE-22052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837693#comment-17837693 ] Pavel Tupitsyn commented on IGNITE-22052: - Test disabled in ac10fb020b1424c81f65572acf7401442c2e1ed0 > С++ 3.0: basic_authenticator_test is flaky > -- > > Key: IGNITE-22052 > URL: https://issues.apache.org/jira/browse/IGNITE-22052 > Project: Ignite > Issue Type: Bug > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Igor Sapego >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > basic_authenticator_test is flaky and causes the entire test run failure due > to a timeout: > https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunCppLinuxTests?branch=%3Cdefault%3E=overview=builds#all-projects > Most likely the reason is the same as in IGNITE-20962: > *EnableAuthenticationJob* does not wait for the configuration to be applied > to all nodes. We've added a workaround to .NET test which checks all nodes in > a loop, but it would be better to fix the job itself. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22052) С++ 3.0: basic_authenticator_test is flaky
[ https://issues.apache.org/jira/browse/IGNITE-22052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22052: Description: basic_authenticator_test is flaky and causes the entire test run failure due to a timeout: https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunCppLinuxTests?branch=%3Cdefault%3E=overview=builds#all-projects Most likely the reason is the same as in IGNITE-20962: *EnableAuthenticationJob* does not wait for the configuration to be applied to all nodes. We've added a workaround to .NET test which checks all nodes in a loop, but it would be better to fix the job itself. > С++ 3.0: basic_authenticator_test is flaky > -- > > Key: IGNITE-22052 > URL: https://issues.apache.org/jira/browse/IGNITE-22052 > Project: Ignite > Issue Type: Bug > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Igor Sapego >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > basic_authenticator_test is flaky and causes the entire test run failure due > to a timeout: > https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunCppLinuxTests?branch=%3Cdefault%3E=overview=builds#all-projects > Most likely the reason is the same as in IGNITE-20962: > *EnableAuthenticationJob* does not wait for the configuration to be applied > to all nodes. We've added a workaround to .NET test which checks all nodes in > a loop, but it would be better to fix the job itself. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22052) С++ 3.0: basic_authenticator_test is flaky
Pavel Tupitsyn created IGNITE-22052: --- Summary: С++ 3.0: basic_authenticator_test is flaky Key: IGNITE-22052 URL: https://issues.apache.org/jira/browse/IGNITE-22052 Project: Ignite Issue Type: Bug Components: platforms, thin client Affects Versions: 3.0.0-beta1 Reporter: Pavel Tupitsyn Assignee: Igor Sapego Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22049) C++: Thin 3.0: Add Gradle task to run tests
[ https://issues.apache.org/jira/browse/IGNITE-22049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22049: Labels: ignite-3 (was: .NET ignite-3) > C++: Thin 3.0: Add Gradle task to run tests > --- > > Key: IGNITE-22049 > URL: https://issues.apache.org/jira/browse/IGNITE-22049 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Add a Gradle task to run .NET tests. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22049) C++: Thin 3.0: Add Gradle task to run tests
Pavel Tupitsyn created IGNITE-22049: --- Summary: C++: Thin 3.0: Add Gradle task to run tests Key: IGNITE-22049 URL: https://issues.apache.org/jira/browse/IGNITE-22049 Project: Ignite Issue Type: Improvement Components: platforms, thin client Affects Versions: 3.0.0-beta1 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 Add a Gradle task to run .NET tests. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22049) C++: Thin 3.0: Add Gradle task to run tests
[ https://issues.apache.org/jira/browse/IGNITE-22049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22049: Description: Add a Gradle task to run C++ tests. (was: Add a Gradle task to run .NET tests.) > C++: Thin 3.0: Add Gradle task to run tests > --- > > Key: IGNITE-22049 > URL: https://issues.apache.org/jira/browse/IGNITE-22049 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Add a Gradle task to run C++ tests. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22048) .NET: Thin 3.0: Add Gradle task to run tests
Pavel Tupitsyn created IGNITE-22048: --- Summary: .NET: Thin 3.0: Add Gradle task to run tests Key: IGNITE-22048 URL: https://issues.apache.org/jira/browse/IGNITE-22048 Project: Ignite Issue Type: Improvement Components: platforms, thin client Affects Versions: 3.0.0-beta1 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 Add a Gradle task to run .NET tests. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22030) Thin 3.0: Remove jackson-dataformat-msgpack dependency
[ https://issues.apache.org/jira/browse/IGNITE-22030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836239#comment-17836239 ] Pavel Tupitsyn commented on IGNITE-22030: - Merged to master: d1635529efecf298b0c0d8761c89e89f316e8dbe > Thin 3.0: Remove jackson-dataformat-msgpack dependency > -- > > Key: IGNITE-22030 > URL: https://issues.apache.org/jira/browse/IGNITE-22030 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > jackson-dataformat-msgpack dependency is not used, remove it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22031) .NET: Thin 3.0: Remove DataStreamer.PartitionAssignmentUpdateFrequency
[ https://issues.apache.org/jira/browse/IGNITE-22031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22031: Description: Timer-based partition assignment check is not necessary. *Table.GetPartitionAssignmentAsync* is backed by a cache with a double-checked locking, and uses a *ValueTask*, so there is no overhead in case of unchanged assignment - we can call it as often as needed. > .NET: Thin 3.0: Remove DataStreamer.PartitionAssignmentUpdateFrequency > -- > > Key: IGNITE-22031 > URL: https://issues.apache.org/jira/browse/IGNITE-22031 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > > Timer-based partition assignment check is not necessary. > *Table.GetPartitionAssignmentAsync* is backed by a cache with a > double-checked locking, and uses a *ValueTask*, so there is no overhead in > case of unchanged assignment - we can call it as often as needed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22031) .NET: Thin 3.0: Remove DataStreamer.PartitionAssignmentUpdateFrequency
Pavel Tupitsyn created IGNITE-22031: --- Summary: .NET: Thin 3.0: Remove DataStreamer.PartitionAssignmentUpdateFrequency Key: IGNITE-22031 URL: https://issues.apache.org/jira/browse/IGNITE-22031 Project: Ignite Issue Type: Improvement Components: platforms, thin client Affects Versions: 3.0.0-beta1 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22030) Thin 3.0: Remove jackson-dataformat-msgpack dependency
Pavel Tupitsyn created IGNITE-22030: --- Summary: Thin 3.0: Remove jackson-dataformat-msgpack dependency Key: IGNITE-22030 URL: https://issues.apache.org/jira/browse/IGNITE-22030 Project: Ignite Issue Type: Improvement Components: thin client Affects Versions: 3.0.0-beta1 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 jackson-dataformat-msgpack dependency is not used, remove it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22025) .NET: Console.WriteLine leftovers in DataStreamer
[ https://issues.apache.org/jira/browse/IGNITE-22025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17835794#comment-17835794 ] Pavel Tupitsyn commented on IGNITE-22025: - Merged to main: 0ce74471ded506fac8bea5160a958461d880b590 > .NET: Console.WriteLine leftovers in DataStreamer > - > > Key: IGNITE-22025 > URL: https://issues.apache.org/jira/browse/IGNITE-22025 > Project: Ignite > Issue Type: Bug > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > *DataStreamer* class has some console output remaining from debugging > sessions - remove that. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22025) .NET: Console.WriteLine leftovers in DataStreamer
[ https://issues.apache.org/jira/browse/IGNITE-22025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22025: Description: *DataStreamer* class has some console output remaining from debugging sessions - remove that. (was: *DataStreamer* class has some console output remaining from debugging sessions - remove them.) > .NET: Console.WriteLine leftovers in DataStreamer > - > > Key: IGNITE-22025 > URL: https://issues.apache.org/jira/browse/IGNITE-22025 > Project: Ignite > Issue Type: Bug > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > *DataStreamer* class has some console output remaining from debugging > sessions - remove that. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22025) .NET: Console.WriteLine leftovers in DataStreamer
[ https://issues.apache.org/jira/browse/IGNITE-22025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22025: Description: *DataStreamer* class has some console output remaining from debugging sessions - remove them. > .NET: Console.WriteLine leftovers in DataStreamer > - > > Key: IGNITE-22025 > URL: https://issues.apache.org/jira/browse/IGNITE-22025 > Project: Ignite > Issue Type: Bug > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > *DataStreamer* class has some console output remaining from debugging > sessions - remove them. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22025) .NET: Console.WriteLine leftovers in DataStreamer
Pavel Tupitsyn created IGNITE-22025: --- Summary: .NET: Console.WriteLine leftovers in DataStreamer Key: IGNITE-22025 URL: https://issues.apache.org/jira/browse/IGNITE-22025 Project: Ignite Issue Type: Bug Components: platforms, thin client Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22019) Different behavior of get() and getAll() wrt key marshalling
[
https://issues.apache.org/jira/browse/IGNITE-22019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-22019:
Fix Version/s: 3.0.0-beta2
> Different behavior of get() and getAll() wrt key marshalling
>
>
> Key: IGNITE-22019
> URL: https://issues.apache.org/jira/browse/IGNITE-22019
> Project: Ignite
> Issue Type: Bug
>Reporter: Roman Puchkovskiy
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Create a table: CREATE TABLE test (id int, val varchar, PRIMARY KEY USING
> HASH (id))
> The add a column 'added int'.
> Then
> private static class Value {
> private @Nullable String val;
> private Value()
> {
> }
> private Value(@Nullable String val)
> {
> this.val = val;
> }
> }
> KeyValueView view =
> CLUSTER.aliveNode().tables().table(TABLE_NAME).keyValueView(Integer.class,
> Value.class);
> Doing view.get(null, 10) throws the following exception:
>
> Caused by: java.lang.IllegalArgumentException: No mapped object field found
> for column 'ADDED'
> at
> org.apache.ignite.internal.marshaller.Marshaller.pojoMarshaller(Marshaller.java:133)
> at
> org.apache.ignite.internal.marshaller.Marshaller.createMarshaller(Marshaller.java:64)
> at
> org.apache.ignite.internal.marshaller.ReflectionMarshallersProvider.lambda$getValuesMarshaller$1(ReflectionMarshallersProvider.java:78)
> at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.lambda$doComputeIfAbsent$13(BoundedLocalCache.java:2457)
> at
> java.base/java.util.concurrent.ConcurrentHashMap.compute(ConcurrentHashMap.java:1947)
> at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.doComputeIfAbsent(BoundedLocalCache.java:2455)
> at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.computeIfAbsent(BoundedLocalCache.java:2438)
> at
> com.github.benmanes.caffeine.cache.LocalCache.computeIfAbsent(LocalCache.java:107)
> at
> com.github.benmanes.caffeine.cache.LocalManualCache.get(LocalManualCache.java:62)
> at
> org.apache.ignite.internal.marshaller.ReflectionMarshallersProvider$MarshallerCache.getOrAdd(ReflectionMarshallersProvider.java:127)
> at
> org.apache.ignite.internal.marshaller.ReflectionMarshallersProvider.getValuesMarshaller(ReflectionMarshallersProvider.java:77)
> at
> org.apache.ignite.internal.schema.marshaller.reflection.KvMarshallerImpl.(KvMarshallerImpl.java:77)
> at
> org.apache.ignite.internal.table.KeyValueViewImpl.lambda$new$0(KeyValueViewImpl.java:107)
> at
> org.apache.ignite.internal.table.KeyValueViewImpl.marshaller(KeyValueViewImpl.java:484)
> at
> org.apache.ignite.internal.table.KeyValueViewImpl.marshal(KeyValueViewImpl.java:498)
> at
> org.apache.ignite.internal.table.KeyValueViewImpl.lambda$getAsync$2(KeyValueViewImpl.java:122)
> at
> org.apache.ignite.internal.table.AbstractTableView.lambda$withSchemaSync$1(AbstractTableView.java:162)
> at
> java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106)
> at
> java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
> at
> org.apache.ignite.internal.table.AbstractTableView.withSchemaSync(AbstractTableView.java:162)
> at
> org.apache.ignite.internal.table.AbstractTableView.lambda$withSchemaSync$0(AbstractTableView.java:171)
>
> But doing view.getAll(null, List.of(10, 20)) does not throw anything, the
> operation gets successfully executed.
>
> It seems that both operations must either throw similar/same exceptions, or
> don't throw anything in this situation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22019) Different behavior of get() and getAll() wrt key marshalling
[
https://issues.apache.org/jira/browse/IGNITE-22019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn reassigned IGNITE-22019:
---
Assignee: Pavel Tupitsyn
> Different behavior of get() and getAll() wrt key marshalling
>
>
> Key: IGNITE-22019
> URL: https://issues.apache.org/jira/browse/IGNITE-22019
> Project: Ignite
> Issue Type: Bug
>Reporter: Roman Puchkovskiy
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
>
> Create a table: CREATE TABLE test (id int, val varchar, PRIMARY KEY USING
> HASH (id))
> The add a column 'added int'.
> Then
> private static class Value {
> private @Nullable String val;
> private Value()
> {
> }
> private Value(@Nullable String val)
> {
> this.val = val;
> }
> }
> KeyValueView view =
> CLUSTER.aliveNode().tables().table(TABLE_NAME).keyValueView(Integer.class,
> Value.class);
> Doing view.get(null, 10) throws the following exception:
>
> Caused by: java.lang.IllegalArgumentException: No mapped object field found
> for column 'ADDED'
> at
> org.apache.ignite.internal.marshaller.Marshaller.pojoMarshaller(Marshaller.java:133)
> at
> org.apache.ignite.internal.marshaller.Marshaller.createMarshaller(Marshaller.java:64)
> at
> org.apache.ignite.internal.marshaller.ReflectionMarshallersProvider.lambda$getValuesMarshaller$1(ReflectionMarshallersProvider.java:78)
> at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.lambda$doComputeIfAbsent$13(BoundedLocalCache.java:2457)
> at
> java.base/java.util.concurrent.ConcurrentHashMap.compute(ConcurrentHashMap.java:1947)
> at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.doComputeIfAbsent(BoundedLocalCache.java:2455)
> at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.computeIfAbsent(BoundedLocalCache.java:2438)
> at
> com.github.benmanes.caffeine.cache.LocalCache.computeIfAbsent(LocalCache.java:107)
> at
> com.github.benmanes.caffeine.cache.LocalManualCache.get(LocalManualCache.java:62)
> at
> org.apache.ignite.internal.marshaller.ReflectionMarshallersProvider$MarshallerCache.getOrAdd(ReflectionMarshallersProvider.java:127)
> at
> org.apache.ignite.internal.marshaller.ReflectionMarshallersProvider.getValuesMarshaller(ReflectionMarshallersProvider.java:77)
> at
> org.apache.ignite.internal.schema.marshaller.reflection.KvMarshallerImpl.(KvMarshallerImpl.java:77)
> at
> org.apache.ignite.internal.table.KeyValueViewImpl.lambda$new$0(KeyValueViewImpl.java:107)
> at
> org.apache.ignite.internal.table.KeyValueViewImpl.marshaller(KeyValueViewImpl.java:484)
> at
> org.apache.ignite.internal.table.KeyValueViewImpl.marshal(KeyValueViewImpl.java:498)
> at
> org.apache.ignite.internal.table.KeyValueViewImpl.lambda$getAsync$2(KeyValueViewImpl.java:122)
> at
> org.apache.ignite.internal.table.AbstractTableView.lambda$withSchemaSync$1(AbstractTableView.java:162)
> at
> java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106)
> at
> java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
> at
> org.apache.ignite.internal.table.AbstractTableView.withSchemaSync(AbstractTableView.java:162)
> at
> org.apache.ignite.internal.table.AbstractTableView.lambda$withSchemaSync$0(AbstractTableView.java:171)
>
> But doing view.getAll(null, List.of(10, 20)) does not throw anything, the
> operation gets successfully executed.
>
> It seems that both operations must either throw similar/same exceptions, or
> don't throw anything in this situation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22019) Different behavior of get() and getAll() wrt key marshalling
[
https://issues.apache.org/jira/browse/IGNITE-22019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn reassigned IGNITE-22019:
---
Assignee: (was: Pavel Tupitsyn)
> Different behavior of get() and getAll() wrt key marshalling
>
>
> Key: IGNITE-22019
> URL: https://issues.apache.org/jira/browse/IGNITE-22019
> Project: Ignite
> Issue Type: Bug
>Reporter: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Create a table: CREATE TABLE test (id int, val varchar, PRIMARY KEY USING
> HASH (id))
> The add a column 'added int'.
> Then
> private static class Value {
> private @Nullable String val;
> private Value()
> {
> }
> private Value(@Nullable String val)
> {
> this.val = val;
> }
> }
> KeyValueView view =
> CLUSTER.aliveNode().tables().table(TABLE_NAME).keyValueView(Integer.class,
> Value.class);
> Doing view.get(null, 10) throws the following exception:
>
> Caused by: java.lang.IllegalArgumentException: No mapped object field found
> for column 'ADDED'
> at
> org.apache.ignite.internal.marshaller.Marshaller.pojoMarshaller(Marshaller.java:133)
> at
> org.apache.ignite.internal.marshaller.Marshaller.createMarshaller(Marshaller.java:64)
> at
> org.apache.ignite.internal.marshaller.ReflectionMarshallersProvider.lambda$getValuesMarshaller$1(ReflectionMarshallersProvider.java:78)
> at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.lambda$doComputeIfAbsent$13(BoundedLocalCache.java:2457)
> at
> java.base/java.util.concurrent.ConcurrentHashMap.compute(ConcurrentHashMap.java:1947)
> at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.doComputeIfAbsent(BoundedLocalCache.java:2455)
> at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.computeIfAbsent(BoundedLocalCache.java:2438)
> at
> com.github.benmanes.caffeine.cache.LocalCache.computeIfAbsent(LocalCache.java:107)
> at
> com.github.benmanes.caffeine.cache.LocalManualCache.get(LocalManualCache.java:62)
> at
> org.apache.ignite.internal.marshaller.ReflectionMarshallersProvider$MarshallerCache.getOrAdd(ReflectionMarshallersProvider.java:127)
> at
> org.apache.ignite.internal.marshaller.ReflectionMarshallersProvider.getValuesMarshaller(ReflectionMarshallersProvider.java:77)
> at
> org.apache.ignite.internal.schema.marshaller.reflection.KvMarshallerImpl.(KvMarshallerImpl.java:77)
> at
> org.apache.ignite.internal.table.KeyValueViewImpl.lambda$new$0(KeyValueViewImpl.java:107)
> at
> org.apache.ignite.internal.table.KeyValueViewImpl.marshaller(KeyValueViewImpl.java:484)
> at
> org.apache.ignite.internal.table.KeyValueViewImpl.marshal(KeyValueViewImpl.java:498)
> at
> org.apache.ignite.internal.table.KeyValueViewImpl.lambda$getAsync$2(KeyValueViewImpl.java:122)
> at
> org.apache.ignite.internal.table.AbstractTableView.lambda$withSchemaSync$1(AbstractTableView.java:162)
> at
> java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106)
> at
> java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
> at
> org.apache.ignite.internal.table.AbstractTableView.withSchemaSync(AbstractTableView.java:162)
> at
> org.apache.ignite.internal.table.AbstractTableView.lambda$withSchemaSync$0(AbstractTableView.java:171)
>
> But doing view.getAll(null, List.of(10, 20)) does not throw anything, the
> operation gets successfully executed.
>
> It seems that both operations must either throw similar/same exceptions, or
> don't throw anything in this situation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22013) Java thin 3.0: KeyValueView does not work with single-column table
[
https://issues.apache.org/jira/browse/IGNITE-22013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-22013:
Description:
Add the following test to *ItTablePutGetEmbeddedTest*, it works in embedded
mode, but not in thin client mode:
{code:java}
@Test
public void testKVWithoutVClient() {
String tableName = "TEST_TABLE_1";
sql("CREATE TABLE " + tableName + " (id int primary key)");
sql("INSERT INTO " + tableName + " (id) VALUES (1)");
KeyValueView kvView =
tables().table(tableName).keyValueView();
Assertions.assertDoesNotThrow(() -> kvView.get(null,
Tuple.create().set("id", 1)));
}
{code}
Exception:
{code}
org.opentest4j.AssertionFailedError: Unexpected exception thrown:
org.apache.ignite.lang.IgniteException: Failed to deserialize server response:
columnCount > 0
at
org.apache.ignite.internal.table.ItTablePutGetEmbeddedTest.testKVWithoutVClient(ItTablePutGetEmbeddedTest.java:57)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
Caused by: org.apache.ignite.lang.IgniteException: IGN-CLIENT-2
TraceId:3301aea6-56cd-4aa5-862d-e5de576ff50e Failed to deserialize server
response: columnCount > 0
at
java.base/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710)
at
org.apache.ignite.internal.util.ExceptionUtils$1.copy(ExceptionUtils.java:765)
at
org.apache.ignite.internal.util.ExceptionUtils$ExceptionFactory.createCopy(ExceptionUtils.java:699)
at
org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:525)
at
org.apache.ignite.internal.client.ClientUtils.copyExceptionWithCauseIfPossible(ClientUtils.java:73)
at
org.apache.ignite.internal.client.ClientUtils.ensurePublicException(ClientUtils.java:54)
at
org.apache.ignite.internal.client.ClientUtils.sync(ClientUtils.java:97)
at
org.apache.ignite.internal.client.table.ClientKeyValueBinaryView.get(ClientKeyValueBinaryView.java:75)
at
org.apache.ignite.internal.client.table.ClientKeyValueBinaryView.get(ClientKeyValueBinaryView.java:56)
at
org.apache.ignite.internal.table.ItTablePutGetEmbeddedTest.lambda$testKVWithoutVClient$0(ItTablePutGetEmbeddedTest.java:57)
... 4 more
Caused by: org.apache.ignite.lang.IgniteException: IGN-CLIENT-2
TraceId:3301aea6-56cd-4aa5-862d-e5de576ff50e Failed to deserialize server
response: columnCount > 0
at
org.apache.ignite.internal.client.TcpClientChannel.complete(TcpClientChannel.java:376)
at
org.apache.ignite.internal.client.TcpClientChannel.processNextMessage(TcpClientChannel.java:415)
at
org.apache.ignite.internal.client.TcpClientChannel.lambda$onMessage$3(TcpClientChannel.java:238)
at
java.base/java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1426)
at
java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
at
java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
at
java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
at
java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
at
java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
Caused by: java.lang.AssertionError: columnCount > 0
at
org.apache.ignite.internal.client.table.MutableTupleBinaryTupleAdapter.(MutableTupleBinaryTupleAdapter.java:59)
at
org.apache.ignite.internal.client.table.ClientTuple.(ClientTuple.java:58)
at
org.apache.ignite.internal.client.table.ClientTupleSerializer.readValueTuple(ClientTupleSerializer.java:340)
at
org.apache.ignite.internal.client.table.ClientKeyValueBinaryView.lambda$getAsync$1(ClientKeyValueBinaryView.java:86)
at
org.apache.ignite.internal.client.table.ClientTable.readSchemaAndReadData(ClientTable.java:511)
at
org.apache.ignite.internal.client.table.ClientTable.lambda$doSchemaOutInOpAsync$6(ClientTable.java:427)
at
org.apache.ignite.internal.client.TcpClientChannel.complete(TcpClientChannel.java:370)
... 8 more
{code}
* Add a test for .NET client too
was:
Add the following test to *ItTablePutGetEmbeddedTest*, it works in embedded
mode, but not in thin client mode:
{code:java}
@Test
public void testKVWithoutVClient() {
String tableName = "TEST_TABLE_1";
sql("CREATE TABLE " + tableName + " (id int primary key)");
sql("INSERT INTO " + tableName + " (id) VALUES (1)");
KeyValueView kvView =
tables().table(tableName).keyValueView();
Assertions.assertDoesNotThrow(() -> kvView.get(null,
Tuple.create().set("id",
[jira] [Updated] (IGNITE-22013) Java thin 3.0: KeyValueView does not work with single-column table
[
https://issues.apache.org/jira/browse/IGNITE-22013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-22013:
Component/s: thin client
> Java thin 3.0: KeyValueView does not work with single-column table
> --
>
> Key: IGNITE-22013
> URL: https://issues.apache.org/jira/browse/IGNITE-22013
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
>
> Add the following test to *ItTablePutGetEmbeddedTest*, it works in embedded
> mode, but not in thin client mode:
> {code:java}
> @Test
> public void testKVWithoutVClient() {
> String tableName = "TEST_TABLE_1";
> sql("CREATE TABLE " + tableName + " (id int primary key)");
> sql("INSERT INTO " + tableName + " (id) VALUES (1)");
> KeyValueView kvView =
> tables().table(tableName).keyValueView();
> Assertions.assertDoesNotThrow(() -> kvView.get(null,
> Tuple.create().set("id", 1)));
> }
> {code}
> * Add a test for .NET client too
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22013) Java thin 3.0: KeyValueView does not work with single-column table
[
https://issues.apache.org/jira/browse/IGNITE-22013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn reassigned IGNITE-22013:
---
Assignee: Pavel Tupitsyn
> Java thin 3.0: KeyValueView does not work with single-column table
> --
>
> Key: IGNITE-22013
> URL: https://issues.apache.org/jira/browse/IGNITE-22013
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
>
> Add the following test to *ItTablePutGetEmbeddedTest*, it works in embedded
> mode, but not in thin client mode:
> {code:java}
> @Test
> public void testKVWithoutVClient() {
> String tableName = "TEST_TABLE_1";
> sql("CREATE TABLE " + tableName + " (id int primary key)");
> sql("INSERT INTO " + tableName + " (id) VALUES (1)");
> KeyValueView kvView =
> tables().table(tableName).keyValueView();
> Assertions.assertDoesNotThrow(() -> kvView.get(null,
> Tuple.create().set("id", 1)));
> }
> {code}
> * Add a test for .NET client too
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22013) Java thin 3.0: KeyValueView does not work with single-column table
[
https://issues.apache.org/jira/browse/IGNITE-22013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-22013:
Fix Version/s: 3.0.0-beta2
> Java thin 3.0: KeyValueView does not work with single-column table
> --
>
> Key: IGNITE-22013
> URL: https://issues.apache.org/jira/browse/IGNITE-22013
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Add the following test to *ItTablePutGetEmbeddedTest*, it works in embedded
> mode, but not in thin client mode:
> {code:java}
> @Test
> public void testKVWithoutVClient() {
> String tableName = "TEST_TABLE_1";
> sql("CREATE TABLE " + tableName + " (id int primary key)");
> sql("INSERT INTO " + tableName + " (id) VALUES (1)");
> KeyValueView kvView =
> tables().table(tableName).keyValueView();
> Assertions.assertDoesNotThrow(() -> kvView.get(null,
> Tuple.create().set("id", 1)));
> }
> {code}
> * Add a test for .NET client too
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22013) Java thin 3.0: KeyValueView does not work with single-column table
[
https://issues.apache.org/jira/browse/IGNITE-22013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-22013:
Description:
Add the following test to *ItTablePutGetEmbeddedTest*, it works in embedded
mode, but not in thin client mode:
{code:java}
@Test
public void testKVWithoutVClient() {
String tableName = "TEST_TABLE_1";
sql("CREATE TABLE " + tableName + " (id int primary key)");
sql("INSERT INTO " + tableName + " (id) VALUES (1)");
KeyValueView kvView =
tables().table(tableName).keyValueView();
Assertions.assertDoesNotThrow(() -> kvView.get(null,
Tuple.create().set("id", 1)));
}
{code}
* Add a test for .NET client too
> Java thin 3.0: KeyValueView does not work with single-column table
> --
>
> Key: IGNITE-22013
> URL: https://issues.apache.org/jira/browse/IGNITE-22013
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
>
> Add the following test to *ItTablePutGetEmbeddedTest*, it works in embedded
> mode, but not in thin client mode:
> {code:java}
> @Test
> public void testKVWithoutVClient() {
> String tableName = "TEST_TABLE_1";
> sql("CREATE TABLE " + tableName + " (id int primary key)");
> sql("INSERT INTO " + tableName + " (id) VALUES (1)");
> KeyValueView kvView =
> tables().table(tableName).keyValueView();
> Assertions.assertDoesNotThrow(() -> kvView.get(null,
> Tuple.create().set("id", 1)));
> }
> {code}
> * Add a test for .NET client too
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22013) Java thin 3.0: KeyValueView does not work with single-column table
Pavel Tupitsyn created IGNITE-22013: --- Summary: Java thin 3.0: KeyValueView does not work with single-column table Key: IGNITE-22013 URL: https://issues.apache.org/jira/browse/IGNITE-22013 Project: Ignite Issue Type: Bug Reporter: Pavel Tupitsyn -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22010) .NET: Thin 3.0: Tracing with OpenTelemetry
Pavel Tupitsyn created IGNITE-22010: --- Summary: .NET: Thin 3.0: Tracing with OpenTelemetry Key: IGNITE-22010 URL: https://issues.apache.org/jira/browse/IGNITE-22010 Project: Ignite Issue Type: New Feature Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 Implement tracing with OpenTelemetry in .NET client. See Npgsql as an example: https://www.npgsql.org/doc/diagnostics/tracing.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21494) Data Streamer: use one shared executor per node for flushTimer
[ https://issues.apache.org/jira/browse/IGNITE-21494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17835299#comment-17835299 ] Pavel Tupitsyn commented on IGNITE-21494: - Merged to main: e067aeae9d3d5f1d8eb5ab9816ce7ce4417c4d86 > Data Streamer: use one shared executor per node for flushTimer > -- > > Key: IGNITE-21494 > URL: https://issues.apache.org/jira/browse/IGNITE-21494 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Currently, every *StreamerSubscriber* instance creates a new > *SingleThreadScheduledExecutor* for the *flushTimer*, which means a new > thread for every streamer. > This is excessive. One executor per node or client should be enough. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21998) .NET: TestSchemaUpdateWhileStreaming is flaky
[
https://issues.apache.org/jira/browse/IGNITE-21998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-21998:
Description:
https://ci.ignite.apache.org/test/4007460749051703227?currentProjectId=ApacheIgnite3xGradle_Test=%3Cdefault%3E=true
Fails due to a 15s timeout or throws an exception:
{code}
Apache.Ignite.IgniteException : Table schema was updated after the transaction
was started [table=108, startSchema=1, operationSchema=2]
> Apache.Ignite.IgniteException :
org.apache.ignite.internal.table.distributed.replicator.IncompatibleSchemaException:
IGN-TX-12 TraceId:e32316b9-eb22-49b2-a45b-01ecb067da4f Table schema was
updated after the transaction was started [table=108, startSchema=1,
operationSchema=2]
at
org.apache.ignite.internal.table.distributed.replicator.SchemaCompatibilityValidator.failIfSchemaChangedAfterTxStart(SchemaCompatibilityValidator.java:238)
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.failIfSchemaChangedSinceTxStart(PartitionReplicaListener.java:3788)
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$validateWriteAgainstSchemaAfterTakingLocks$215(PartitionReplicaListener.java:3713)
at
java.base/java.util.concurrent.CompletableFuture.uniApplyNow(CompletableFuture.java:680)
at
java.base/java.util.concurrent.CompletableFuture.uniApplyStage(CompletableFuture.java:658)
at
java.base/java.util.concurrent.CompletableFuture.thenApply(CompletableFuture.java:2094)
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.validateWriteAgainstSchemaAfterTakingLocks(PartitionReplicaListener.java:3712)
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$processMultiEntryAction$106(PartitionReplicaListener.java:2377)
at
java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106)
at
java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.processMultiEntryAction(PartitionReplicaListener.java:2349)
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$processOperationRequest$11(PartitionReplicaListener.java:644)
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.appendTxCommand(PartitionReplicaListener.java:1926)
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.processOperationRequest(PartitionReplicaListener.java:644)
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.processOperationRequestWithTxRwCounter(PartitionReplicaListener.java:3923)
at
org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$processRequest$5(PartitionReplicaListener.java:440)
at
java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base/java.util.concurrent.CompletableFuture.postFire(CompletableFuture.java:610)
at
java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:649)
at
java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
at Apache.Ignite.Internal.ClientSocket.DoOutInOpAsyncInternal(ClientOp
clientOp, PooledArrayBuffer request, Boolean expectNotifications) in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/ClientSocket.cs:line
626
at
Apache.Ignite.Internal.ClientFailoverSocket.DoOutInOpAndGetSocketAsync(ClientOp
clientOp, Transaction tx, PooledArrayBuffer request, PreferredNode
preferredNode, IRetryPolicy retryPolicyOverride, Boolean expectNotifications)
in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/ClientFailoverSocket.cs:line
213
at Apache.Ignite.Internal.Table.DataStreamer.SendBatchAsync(Table table,
PooledArrayBuffer buf, Int32 count, PreferredNode preferredNode, IRetryPolicy
retryPolicy) in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/Table/DataStreamer.cs:line
509
at
Apache.Ignite.Internal.Table.DataStreamer.<>c__DisplayClass1_0`1.d.MoveNext()
in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/Table/DataStreamer.cs:line
312
--- End of stack trace from previous location ---
at
[jira] [Updated] (IGNITE-21998) .NET: TestSchemaUpdateWhileStreaming is flaky
[ https://issues.apache.org/jira/browse/IGNITE-21998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-21998: Description: https://ci.ignite.apache.org/test/4007460749051703227?currentProjectId=ApacheIgnite3xGradle_Test=%3Cdefault%3E=true > .NET: TestSchemaUpdateWhileStreaming is flaky > - > > Key: IGNITE-21998 > URL: https://issues.apache.org/jira/browse/IGNITE-21998 > Project: Ignite > Issue Type: Bug > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > > https://ci.ignite.apache.org/test/4007460749051703227?currentProjectId=ApacheIgnite3xGradle_Test=%3Cdefault%3E=true -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21998) .NET: TestSchemaUpdateWhileStreaming is flaky
Pavel Tupitsyn created IGNITE-21998: --- Summary: .NET: TestSchemaUpdateWhileStreaming is flaky Key: IGNITE-21998 URL: https://issues.apache.org/jira/browse/IGNITE-21998 Project: Ignite Issue Type: Bug Components: thin client Affects Versions: 3.0.0-beta1 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21490) .NET: Thin 3.0: DataStreamer data removal
[ https://issues.apache.org/jira/browse/IGNITE-21490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17834851#comment-17834851 ] Pavel Tupitsyn commented on IGNITE-21490: - Merged to main: 9a24cc614535c2e668cc0871bec1f1fee5928d29 > .NET: Thin 3.0: DataStreamer data removal > - > > Key: IGNITE-21490 > URL: https://issues.apache.org/jira/browse/IGNITE-21490 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > Implement data removal in .NET data streamer - see Java API changes in > IGNITE-21403. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21494) Data Streamer: use one shared executor per node for flushTimer
[ https://issues.apache.org/jira/browse/IGNITE-21494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-21494: Description: Currently, every *StreamerSubscriber* instance creates a new *SingleThreadScheduledExecutor* for the *flushTimer*, which means a new thread for every streamer. This is excessive. One executor per node or client should be enough. was: Currently, every *StreamSubscriber* instance creates a new *SingleThreadScheduledExecutor* for the *flushTimer*, which means a new thread for every streamer. This is excessive. One executor per node or client should be enough. > Data Streamer: use one shared executor per node for flushTimer > -- > > Key: IGNITE-21494 > URL: https://issues.apache.org/jira/browse/IGNITE-21494 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Currently, every *StreamerSubscriber* instance creates a new > *SingleThreadScheduledExecutor* for the *flushTimer*, which means a new > thread for every streamer. > This is excessive. One executor per node or client should be enough. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21099) .NET: Thin 3.0: Ensure AOT compatibility
[ https://issues.apache.org/jira/browse/IGNITE-21099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-21099: Description: Ensure that Ignite.NET library is AOT-compatible: https://devblogs.microsoft.com/dotnet/creating-aot-compatible-libraries/ To test this: * Run existing tests in AOT mode? Not sure if NUnit can do that. * Write separate tests to check basic functionality for AOT * See https://devblogs.microsoft.com/dotnet/testing-your-native-aot-dotnet-apps/ (note: experimental, closed-source testing framework) was: Ensure that Ignite.NET library is AOT-compatible: https://devblogs.microsoft.com/dotnet/creating-aot-compatible-libraries/ To test this: * Run existing tests in AOT mode? Not sure if NUnit can do that. * Write separate tests to check basic functionality for AOT * See https://devblogs.microsoft.com/dotnet/testing-your-native-aot-dotnet-apps/ > .NET: Thin 3.0: Ensure AOT compatibility > > > Key: IGNITE-21099 > URL: https://issues.apache.org/jira/browse/IGNITE-21099 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > > Ensure that Ignite.NET library is AOT-compatible: > https://devblogs.microsoft.com/dotnet/creating-aot-compatible-libraries/ > To test this: > * Run existing tests in AOT mode? Not sure if NUnit can do that. > * Write separate tests to check basic functionality for AOT > * See > https://devblogs.microsoft.com/dotnet/testing-your-native-aot-dotnet-apps/ > (note: experimental, closed-source testing framework) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21099) .NET: Thin 3.0: Ensure AOT compatibility
[ https://issues.apache.org/jira/browse/IGNITE-21099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-21099: Description: Ensure that Ignite.NET library is AOT-compatible: https://devblogs.microsoft.com/dotnet/creating-aot-compatible-libraries/ To test this: * Run existing tests in AOT mode? Not sure if NUnit can do that. * Write separate tests to check basic functionality for AOT * See https://devblogs.microsoft.com/dotnet/testing-your-native-aot-dotnet-apps/ was: Ensure that Ignite.NET library is AOT-compatible: https://devblogs.microsoft.com/dotnet/creating-aot-compatible-libraries/ To test this: * Run existing tests in AOT mode? Not sure if NUnit can do that. * Write separate tests to check basic functionality for AOT > .NET: Thin 3.0: Ensure AOT compatibility > > > Key: IGNITE-21099 > URL: https://issues.apache.org/jira/browse/IGNITE-21099 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > > Ensure that Ignite.NET library is AOT-compatible: > https://devblogs.microsoft.com/dotnet/creating-aot-compatible-libraries/ > To test this: > * Run existing tests in AOT mode? Not sure if NUnit can do that. > * Write separate tests to check basic functionality for AOT > * See > https://devblogs.microsoft.com/dotnet/testing-your-native-aot-dotnet-apps/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21962) ignite-client-handler tests fail due to hardcoded handshake response size
[ https://issues.apache.org/jira/browse/IGNITE-21962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-21962: Description: The following tests fail if you change *IgniteProductVersion.CURRENT_VERSION* so that the string length is different, because handshake response size changes: * *org.apache.ignite.client.handler.ItClientHandlerMetricsTest#testBytesSentReceived* * *org.apache.ignite.client.handler.ItClientHandlerTest#testHandshakeWithAuthenticationValidCredentials* * *org.apache.ignite.client.handler.ItClientHandlerTest#testHandshakeValidReturnsSuccess* was: * *org.apache.ignite.client.handler.ItClientHandlerMetricsTest#testBytesSentReceived* * *org.apache.ignite.client.handler.ItClientHandlerTest#testHandshakeWithAuthenticationValidCredentials* * *org.apache.ignite.client.handler.ItClientHandlerTest#testHandshakeValidReturnsSuccess* > ignite-client-handler tests fail due to hardcoded handshake response size > - > > Key: IGNITE-21962 > URL: https://issues.apache.org/jira/browse/IGNITE-21962 > Project: Ignite > Issue Type: Bug > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > The following tests fail if you change *IgniteProductVersion.CURRENT_VERSION* > so that the string length is different, because handshake response size > changes: > > * > *org.apache.ignite.client.handler.ItClientHandlerMetricsTest#testBytesSentReceived* > * > *org.apache.ignite.client.handler.ItClientHandlerTest#testHandshakeWithAuthenticationValidCredentials* > * > *org.apache.ignite.client.handler.ItClientHandlerTest#testHandshakeValidReturnsSuccess* -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21962) ignite-client-handler tests fail due to hardcoded handshake response size
[ https://issues.apache.org/jira/browse/IGNITE-21962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-21962: Description: * *org.apache.ignite.client.handler.ItClientHandlerMetricsTest#testBytesSentReceived* * *org.apache.ignite.client.handler.ItClientHandlerTest#testHandshakeWithAuthenticationValidCredentials* * *org.apache.ignite.client.handler.ItClientHandlerTest#testHandshakeValidReturnsSuccess* > ignite-client-handler tests fail due to hardcoded handshake response size > - > > Key: IGNITE-21962 > URL: https://issues.apache.org/jira/browse/IGNITE-21962 > Project: Ignite > Issue Type: Bug > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > * > *org.apache.ignite.client.handler.ItClientHandlerMetricsTest#testBytesSentReceived* > * > *org.apache.ignite.client.handler.ItClientHandlerTest#testHandshakeWithAuthenticationValidCredentials* > * > *org.apache.ignite.client.handler.ItClientHandlerTest#testHandshakeValidReturnsSuccess* -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21962) ignite-client-handler tests fail due to hardcoded handshake response size
Pavel Tupitsyn created IGNITE-21962: --- Summary: ignite-client-handler tests fail due to hardcoded handshake response size Key: IGNITE-21962 URL: https://issues.apache.org/jira/browse/IGNITE-21962 Project: Ignite Issue Type: Bug Components: thin client Affects Versions: 3.0.0-beta1 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21931) .NET: Thin 3.0: Refactor DataStreamer to use StreamerBatchSend
[ https://issues.apache.org/jira/browse/IGNITE-21931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833571#comment-17833571 ] Pavel Tupitsyn commented on IGNITE-21931: - Merged to main: d3ff291c4c63694af9dcf3714ec983c2a20fcc21 > .NET: Thin 3.0: Refactor DataStreamer to use StreamerBatchSend > -- > > Key: IGNITE-21931 > URL: https://issues.apache.org/jira/browse/IGNITE-21931 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > Implement IGNITE-21402 in .NET: Use *StreamerBatchSend* instead of > *TupleUpsertAll* protocol operation for data streamer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21931) .NET: Thin 3.0: Refactor DataStreamer to use StreamerBatchSend
[ https://issues.apache.org/jira/browse/IGNITE-21931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833506#comment-17833506 ] Pavel Tupitsyn commented on IGNITE-21931: - [~isapego] please review. > .NET: Thin 3.0: Refactor DataStreamer to use StreamerBatchSend > -- > > Key: IGNITE-21931 > URL: https://issues.apache.org/jira/browse/IGNITE-21931 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Implement IGNITE-21402 in .NET: Use *StreamerBatchSend* instead of > *TupleUpsertAll* protocol operation for data streamer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21931) .NET: Thin 3.0: Refactor DataStreamer to use StreamerBatchSend
[ https://issues.apache.org/jira/browse/IGNITE-21931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-21931: Description: Implement IGNITE-21402 in .NET: Use > .NET: Thin 3.0: Refactor DataStreamer to use StreamerBatchSend > -- > > Key: IGNITE-21931 > URL: https://issues.apache.org/jira/browse/IGNITE-21931 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Implement IGNITE-21402 in .NET: Use -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21931) .NET: Thin 3.0: Refactor DataStreamer to use StreamerBatchSend
[ https://issues.apache.org/jira/browse/IGNITE-21931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-21931: Description: Implement IGNITE-21402 in .NET: Use *StreamerBatchSend* instead of *TupleUpsertAll* protocol operation for data streamer. (was: Implement IGNITE-21402 in .NET: Use ) > .NET: Thin 3.0: Refactor DataStreamer to use StreamerBatchSend > -- > > Key: IGNITE-21931 > URL: https://issues.apache.org/jira/browse/IGNITE-21931 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Implement IGNITE-21402 in .NET: Use *StreamerBatchSend* instead of > *TupleUpsertAll* protocol operation for data streamer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21931) .NET: Thin 3.0: Refactor DataStreamer to use StreamerBatchSend
Pavel Tupitsyn created IGNITE-21931: --- Summary: .NET: Thin 3.0: Refactor DataStreamer to use StreamerBatchSend Key: IGNITE-21931 URL: https://issues.apache.org/jira/browse/IGNITE-21931 Project: Ignite Issue Type: Improvement Components: platforms, thin client Affects Versions: 3.0.0-beta1 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21604) .NET: Thin 3.0: Pass client time zone to server
[ https://issues.apache.org/jira/browse/IGNITE-21604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-21604: --- Assignee: Pavel Tupitsyn > .NET: Thin 3.0: Pass client time zone to server > --- > > Key: IGNITE-21604 > URL: https://issues.apache.org/jira/browse/IGNITE-21604 > Project: Ignite > Issue Type: Improvement > Components: thin client >Reporter: Pavel Pereslegin >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > > Once IGNITE-21551 is implemented, it will be possible to set the time zone in > a user session. > The session time zone is taken into account when calling functions for > obtaining the current time (CURRENT_TIMESTAMP, etc), as well as when > processing a string literal for the 'TIMESTAMP WITH LOCAL TIME ZONE' type. > For this to work correctly, you need to transfer the client's time zone > through the thin client. > p.s. check the TODOs that point to this ticket. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21568) Java thin 3.0: Pass client time zone to server
[ https://issues.apache.org/jira/browse/IGNITE-21568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-21568: --- Assignee: Pavel Tupitsyn > Java thin 3.0: Pass client time zone to server > -- > > Key: IGNITE-21568 > URL: https://issues.apache.org/jira/browse/IGNITE-21568 > Project: Ignite > Issue Type: Improvement > Components: thin client >Reporter: Pavel Pereslegin >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > > Once IGNITE-21551 is implemented, it will be possible to set the time zone in > a user session. > The session time zone is taken into account when calling functions for > obtaining the current time (CURRENT_TIMESTAMP, etc), as well as when > processing a string literal for the 'TIMESTAMP WITH LOCAL TIME ZONE' type. > For this to work correctly, you need to transfer the client's time zone > through the thin client. > p.s. check the TODOs that point to this ticket. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21765) Java thin 3.0: DataStreamer partition awareness might break if assignment is not available at the moment
[ https://issues.apache.org/jira/browse/IGNITE-21765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833129#comment-17833129 ] Pavel Tupitsyn commented on IGNITE-21765: - Merged to main: dd75ada680b6a42b022b61f9615667bca156f4ad > Java thin 3.0: DataStreamer partition awareness might break if assignment is > not available at the moment > > > Key: IGNITE-21765 > URL: https://issues.apache.org/jira/browse/IGNITE-21765 > Project: Ignite > Issue Type: Bug > Components: streaming, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > * *ClientTable.getPartitionAssignment* might return an empty list > * *AbstractClientStreamerPartitionAwarenessProvider* assumes that partition > count can't change > Therefore, if some server node lags behind and returns an empty assignment > for a given timestamp, streamer partition awareness won't work at all. > *Potential Fixes* > * Wait for assignment on the server, do not return empty/null - might affect > performance > * Return correct partition count, but null values - faster and simpler -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21765) Java thin 3.0: DataStreamer partition awareness might break if assignment is not available at the moment
[ https://issues.apache.org/jira/browse/IGNITE-21765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-21765: Ignite Flags: (was: Docs Required,Release Notes Required) > Java thin 3.0: DataStreamer partition awareness might break if assignment is > not available at the moment > > > Key: IGNITE-21765 > URL: https://issues.apache.org/jira/browse/IGNITE-21765 > Project: Ignite > Issue Type: Bug > Components: streaming, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > * *ClientTable.getPartitionAssignment* might return an empty list > * *AbstractClientStreamerPartitionAwarenessProvider* assumes that partition > count can't change > Therefore, if some server node lags behind and returns an empty assignment > for a given timestamp, streamer partition awareness won't work at all. > *Potential Fixes* > * Wait for assignment on the server, do not return empty/null - might affect > performance > * Return correct partition count, but null values - faster and simpler -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (IGNITE-21891) deleteAll/removeAll does not work in embedded mode when key columns are after value
[ https://issues.apache.org/jira/browse/IGNITE-21891 ] Pavel Tupitsyn deleted comment on IGNITE-21891: - was (Author: ptupitsyn): [~isapego] please review. > deleteAll/removeAll does not work in embedded mode when key columns are after > value > --- > > Key: IGNITE-21891 > URL: https://issues.apache.org/jira/browse/IGNITE-21891 > Project: Ignite > Issue Type: Bug >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Priority: Blocker > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > See disabled tests in *ItCustomKeyColumnOrderEmbeddedTest*. > * *deleteAll/removeAll* methods return key-only rows > * *AbstractRowTupleAdapter* does not support key-only rows and always uses > *positionInRow*. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21891) deleteAll/removeAll does not work in embedded mode when key columns are after value
[ https://issues.apache.org/jira/browse/IGNITE-21891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-21891: --- Assignee: Pavel Tupitsyn > deleteAll/removeAll does not work in embedded mode when key columns are after > value > --- > > Key: IGNITE-21891 > URL: https://issues.apache.org/jira/browse/IGNITE-21891 > Project: Ignite > Issue Type: Bug >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Blocker > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > See disabled tests in *ItCustomKeyColumnOrderEmbeddedTest*. > * *deleteAll/removeAll* methods return key-only rows > * *AbstractRowTupleAdapter* does not support key-only rows and always uses > *positionInRow*. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21891) deleteAll/removeAll does not work in embedded mode when key columns are after value
[ https://issues.apache.org/jira/browse/IGNITE-21891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-21891: --- Assignee: (was: Pavel Tupitsyn) > deleteAll/removeAll does not work in embedded mode when key columns are after > value > --- > > Key: IGNITE-21891 > URL: https://issues.apache.org/jira/browse/IGNITE-21891 > Project: Ignite > Issue Type: Bug >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Priority: Blocker > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > See disabled tests in *ItCustomKeyColumnOrderEmbeddedTest*. > * *deleteAll/removeAll* methods return key-only rows > * *AbstractRowTupleAdapter* does not support key-only rows and always uses > *positionInRow*. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21877) Wrong column deserialization order in ClientKeyValueView
[ https://issues.apache.org/jira/browse/IGNITE-21877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832236#comment-17832236 ] Pavel Tupitsyn commented on IGNITE-21877: - Merged to main: 35ef7213b0dc05ba7d32f53eaf918800ecbdfae5 > Wrong column deserialization order in ClientKeyValueView > > > Key: IGNITE-21877 > URL: https://issues.apache.org/jira/browse/IGNITE-21877 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Blocker > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > IGNITE-21768 fix was incomplete - some places still use old logic: > * *readGetAllResponse* > * *queryMapper* > Make sure to add tests for all operations in all views to > *ItCustomKeyColumnOrderClientTest* . -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21891) deleteAll/removeAll does not work in embedded mode when key columns are after value
[ https://issues.apache.org/jira/browse/IGNITE-21891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-21891: Description: See disabled tests in *ItCustomKeyColumnOrderEmbeddedTest*. * *deleteAll/removeAll* methods return key-only rows * *AbstractRowTupleAdapter* does not support key-only rows and always uses *positionInRow*. was: See disabled tests in *ItCustomKeyColumnOrderEmbeddedTest*. *AbstractRowTupleAdapter* does not support key-only rows and always uses *positionInRow*. > deleteAll/removeAll does not work in embedded mode when key columns are after > value > --- > > Key: IGNITE-21891 > URL: https://issues.apache.org/jira/browse/IGNITE-21891 > Project: Ignite > Issue Type: Bug >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Priority: Blocker > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > See disabled tests in *ItCustomKeyColumnOrderEmbeddedTest*. > * *deleteAll/removeAll* methods return key-only rows > * *AbstractRowTupleAdapter* does not support key-only rows and always uses > *positionInRow*. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21891) deleteAll/removeAll does not work in embedded mode when key columns are after value
[ https://issues.apache.org/jira/browse/IGNITE-21891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-21891: Description: See disabled tests in *ItCustomKeyColumnOrderEmbeddedTest*. *AbstractRowTupleAdapter* does not support key-only rows and always uses *positionInRow*. was:See disabled tests in *ItCustomKeyColumnOrderEmbeddedTest*. > deleteAll/removeAll does not work in embedded mode when key columns are after > value > --- > > Key: IGNITE-21891 > URL: https://issues.apache.org/jira/browse/IGNITE-21891 > Project: Ignite > Issue Type: Bug >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Priority: Blocker > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > See disabled tests in *ItCustomKeyColumnOrderEmbeddedTest*. > *AbstractRowTupleAdapter* does not support key-only rows and always uses > *positionInRow*. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21891) deleteAll/removeAll does not work in embedded mode when key columns are after value
[ https://issues.apache.org/jira/browse/IGNITE-21891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-21891: Labels: ignite-3 (was: ) > deleteAll/removeAll does not work in embedded mode when key columns are after > value > --- > > Key: IGNITE-21891 > URL: https://issues.apache.org/jira/browse/IGNITE-21891 > Project: Ignite > Issue Type: Bug >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Priority: Blocker > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > See disabled tests in *ItCustomKeyColumnOrderEmbeddedTest*. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21891) deleteAll/removeAll does not work in embedded mode when key columns are after value
Pavel Tupitsyn created IGNITE-21891: --- Summary: deleteAll/removeAll does not work in embedded mode when key columns are after value Key: IGNITE-21891 URL: https://issues.apache.org/jira/browse/IGNITE-21891 Project: Ignite Issue Type: Bug Affects Versions: 3.0.0-beta1 Reporter: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21891) deleteAll/removeAll does not work in embedded mode when key columns are after value
[ https://issues.apache.org/jira/browse/IGNITE-21891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-21891: Description: See disabled tests in *ItCustomKeyColumnOrderEmbeddedTest*. > deleteAll/removeAll does not work in embedded mode when key columns are after > value > --- > > Key: IGNITE-21891 > URL: https://issues.apache.org/jira/browse/IGNITE-21891 > Project: Ignite > Issue Type: Bug >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Priority: Blocker > Fix For: 3.0.0-beta2 > > > See disabled tests in *ItCustomKeyColumnOrderEmbeddedTest*. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21335) C++ 3.0: Implement JobExecutionOptions
[ https://issues.apache.org/jira/browse/IGNITE-21335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832212#comment-17832212 ] Pavel Tupitsyn commented on IGNITE-21335: - [~isapego] looks good to me. > C++ 3.0: Implement JobExecutionOptions > -- > > Key: IGNITE-21335 > URL: https://issues.apache.org/jira/browse/IGNITE-21335 > Project: Ignite > Issue Type: Task > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Dmitry Baranov >Assignee: Igor Sapego >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Java part of this changes https://github.com/apache/ignite-3/pull/3050 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21745) BinaryTuple stores BigDecimal inefficiently
[
https://issues.apache.org/jira/browse/IGNITE-21745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832185#comment-17832185
]
Pavel Tupitsyn commented on IGNITE-21745:
-
Merged to main: 71c320f0af1a41045a19381e4e859cf38726342a
> BinaryTuple stores BigDecimal inefficiently
> ---
>
> Key: IGNITE-21745
> URL: https://issues.apache.org/jira/browse/IGNITE-21745
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> * While we have varint logic for short/int/long, we don't have it for
> BigDecimal.
> * MAX_DECIMAL_SCALE = Short.MAX_VALUE (CatalogUtils)
> As a result, we can waste multiple kilobytes to store a very simple value.
> {code:java}
> BigDecimal value = new BigDecimal(1);
> BinaryTupleBuilder builder = new BinaryTupleBuilder(1);
> ByteBuffer bytes = builder.appendDecimal(value,
> Short.MAX_VALUE).build();
> assertEquals(13610, bytes.limit());
> {code}
> This is especially a problem with some SQL queries which return values with
> MAX_DECIMAL_SCALE as a result of calculations, for example:
> {code:sql}
> select (cast(_T0.VAL as decimal(20, 10)) / ?) as DECIMAL0 from
> PUBLIC.TBL_INT32 as _T0
> {code}
> Another problem - .NET client can't read those large-scale values because of
> built-in type limitation. Even though the actual value is just *1*.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21288) C++ thin client: implement job execution interface
[
https://issues.apache.org/jira/browse/IGNITE-21288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832086#comment-17832086
]
Pavel Tupitsyn commented on IGNITE-21288:
-
[~isapego] looks good to me in general, please see a few comments on GitHub.
> C++ thin client: implement job execution interface
> --
>
> Key: IGNITE-21288
> URL: https://issues.apache.org/jira/browse/IGNITE-21288
> Project: Ignite
> Issue Type: Improvement
> Components: compute, platforms, thin client
>Reporter: Vadim Pakhnushev
>Assignee: Igor Sapego
>Priority: Major
> Labels: ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Implement {{JobExecution}} interface on the client.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21875) SQL API cleanup - remove properties and reactive methods
[ https://issues.apache.org/jira/browse/IGNITE-21875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-21875: Labels: ignite-3 (was: ) > SQL API cleanup - remove properties and reactive methods > > > Key: IGNITE-21875 > URL: https://issues.apache.org/jira/browse/IGNITE-21875 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > * *Statement#properties* are not used > * Reactive APIs are not implemented > Remove them. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21877) Wrong column deserialization order in ClientKeyValueView
Pavel Tupitsyn created IGNITE-21877: --- Summary: Wrong column deserialization order in ClientKeyValueView Key: IGNITE-21877 URL: https://issues.apache.org/jira/browse/IGNITE-21877 Project: Ignite Issue Type: Improvement Components: thin client Affects Versions: 3.0.0-beta1 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21877) Wrong column deserialization order in ClientKeyValueView
[ https://issues.apache.org/jira/browse/IGNITE-21877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-21877: Description: IGNITE-21768 fix was incomplete - some places still use old logic: * *readGetAllResponse* * *queryMapper* Make sure to add tests for all operations in all views to *ItCustomKeyColumnOrderClientTest* . was: IGNITE-21768 fix was incomplete - some places still use old logic: * *readGetAllResponse* * *queryMapper* > Wrong column deserialization order in ClientKeyValueView > > > Key: IGNITE-21877 > URL: https://issues.apache.org/jira/browse/IGNITE-21877 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Blocker > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > IGNITE-21768 fix was incomplete - some places still use old logic: > * *readGetAllResponse* > * *queryMapper* > Make sure to add tests for all operations in all views to > *ItCustomKeyColumnOrderClientTest* . -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21877) Wrong column deserialization order in ClientKeyValueView
[ https://issues.apache.org/jira/browse/IGNITE-21877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-21877: Description: IGNITE-21768 fix was incomplete - some places still use old logic: * *readGetAllResponse* * *queryMapper* > Wrong column deserialization order in ClientKeyValueView > > > Key: IGNITE-21877 > URL: https://issues.apache.org/jira/browse/IGNITE-21877 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Blocker > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > IGNITE-21768 fix was incomplete - some places still use old logic: > * *readGetAllResponse* > * *queryMapper* -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21875) SQL API cleanup - remove properties and reactive methods
Pavel Tupitsyn created IGNITE-21875: --- Summary: SQL API cleanup - remove properties and reactive methods Key: IGNITE-21875 URL: https://issues.apache.org/jira/browse/IGNITE-21875 Project: Ignite Issue Type: Improvement Components: sql Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21875) SQL API cleanup - remove properties and reactive methods
[ https://issues.apache.org/jira/browse/IGNITE-21875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-21875: Description: * *Statement#properties* are not used * Reactive APIs are not implemented Remove them. > SQL API cleanup - remove properties and reactive methods > > > Key: IGNITE-21875 > URL: https://issues.apache.org/jira/browse/IGNITE-21875 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Fix For: 3.0.0-beta2 > > > * *Statement#properties* are not used > * Reactive APIs are not implemented > Remove them. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21768) Wrong key column serialization in ClientKeyValueView
[ https://issues.apache.org/jira/browse/IGNITE-21768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17831857#comment-17831857 ] Pavel Tupitsyn commented on IGNITE-21768: - Merged to main: c662f45bbe5c89626f1d6739afbf1198c286e1bb > Wrong key column serialization in ClientKeyValueView > > > Key: IGNITE-21768 > URL: https://issues.apache.org/jira/browse/IGNITE-21768 > Project: Ignite > Issue Type: Bug > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Blocker > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Attachments: ItTablePutGetThinWithMarshaller.java > > Time Spent: 20m > Remaining Estimate: 0h > > *ClientKeyValueView.writeKeyValueRaw* was not updated as part of IGNITE-21525 > changes and still uses key-first order. -- This message was sent by Atlassian Jira (v8.20.10#820010)
