Tickets for Ignite 3.x

Igniters, To make sure nothing slips from the scope of Ignite 3.x, I've created a label to mark the corresponding tickets. The label is 'ignite-3'. Please use it if you create any issue related to Ignite 3.x, or if there is an existing issue that you think should be included there. Here is the fi

[jira] [Created] (IGNITE-13416) Ignite 3 test

Valentin Kulichenko created IGNITE-13416: Summary: Ignite 3 test Key: IGNITE-13416 URL: https://issues.apache.org/jira/browse/IGNITE-13416 Project: Ignite Issue Type: Bug

Re: IEP-54: Schema-first approach for 3.0

Hi Denis, I guess the wording in the IEP is a little bit confusing. All it means is that you should not create nested POJOs, but rather inline fields into a single POJO that is mapped to a particular schema. In other words, nested POJOs are not supported. Alex, is this correct? Please let me know

Re: IEP-54: Schema-first approach for 3.0

Val, I've checked the IEP again and have a few questions. Arbitrary nested objects and collections are not allowed as column values. > Nested POJOs should either be inlined into schema, or stored as BLOBs Could you provide a DDL code snippet showing how the inlining of POJOs is supposed to work

[jira] [Created] (IGNITE-13415) Unable to read fields value from BinaryObject

Wasim Bari created IGNITE-13415: --- Summary: Unable to read fields value from BinaryObject Key: IGNITE-13415 URL: https://issues.apache.org/jira/browse/IGNITE-13415 Project: Ignite Issue Type: Bu

Re: Limit/Offset index scan

Vladimir, What do you think about my high-level solution shared in the previous email? What if we implement the SortedSet they way I suggested? - Denis On Tue, Sep 8, 2020 at 4:15 AM Vladimir Pligin wrote: > Denis, > > I absolutely agree with you that a SortedSet doesn't need to be > partitio

Re: Command line interface to manage distributed properties

Hello, Anton. > 1) Publish distributed property I propose to use SystemView API to accomplish this. Actually, there is PR for it, already [1] Distributed property will be available via SQL - «SELECT * FROM SYS.DISTRIBUTED_METASTORAGE» Or via JMX in the corresponding bean. > 2) Permission for d

Re: Command line interface to manage distributed properties

Hi everyone, I think I agree with Nikolay that we should make available all our property not only some of them. Also maybe it makes sense to split this task into two tasks in the following way: Publish all distributed property through public interfaces(control.sh, jmx, etc.), Giving possibility

Re: Limit/Offset index scan

Denis, I absolutely agree with you that a SortedSet doesn't need to be partitioned. The main idea I wanted to put attention on is that now it's not possible to find a row with a particular number with log complexity. We need to scan node-local index until we reach some offset, it seems to be linea

[IGNITE-13404] ignite.sh fails to set default JVM parameters - ASF JIRA

Hi all, I found and created a patch for an issue I discovered last week. The ignite.sh script tries to set default JVM memory parameters if the user didn’t set JVM_OPTS, only those lines of code never get called. > https://issues.apache.org/jira/browse/IGNITE-13404 >

[jira] [Created] (IGNITE-13413) PHP using ODBC corrupts decimal numbers

Ilya Kasnacheev created IGNITE-13413: Summary: PHP using ODBC corrupts decimal numbers Key: IGNITE-13413 URL: https://issues.apache.org/jira/browse/IGNITE-13413 Project: Ignite Issue Type

[jira] [Created] (IGNITE-13414) JDBC thin: compatibility is broken for versions 2.8-2.9

Aleksey Plekhanov created IGNITE-13414: -- Summary: JDBC thin: compatibility is broken for versions 2.8-2.9 Key: IGNITE-13414 URL: https://issues.apache.org/jira/browse/IGNITE-13414 Project: Ignite

Re: [DISCUSSION] Add autocompletion for commands in control.sh

Hello, Ilya! I agree that it would be better if we found a common approach, but I haven't found one yet. 07.09.2020, 18:50, "Ilya Kasnacheev" : > Hello! > > Not everyone is using bash, which leads me to question whether there's any > common approach where we can hint a shell what our executable