[jira] [Commented] (IGNITE-15289) Collect global statistics
[ https://issues.apache.org/jira/browse/IGNITE-15289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17442600#comment-17442600 ] Konstantin Orlov commented on IGNITE-15289: --- Merged to [sql-calcite|https://github.com/apache/ignite/tree/sql-calcite] > Collect global statistics > - > > Key: IGNITE-15289 > URL: https://issues.apache.org/jira/browse/IGNITE-15289 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Alexander Belyak >Assignee: Alexander Belyak >Priority: Major > Time Spent: 7h > Remaining Estimate: 0h > > Collect global statistics by request to use in Calcite cost model. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-15833) Provide interfaces for SQL Extension API
[ https://issues.apache.org/jira/browse/IGNITE-15833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17442594#comment-17442594 ] Alexander Belyak commented on IGNITE-15833: --- [~korlov] Please add licence headers. > Provide interfaces for SQL Extension API > > > Key: IGNITE-15833 > URL: https://issues.apache.org/jira/browse/IGNITE-15833 > Project: Ignite > Issue Type: Sub-task >Reporter: Konstantin Orlov >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > During this task we need to provide minimal yet sufficient interfaces to make > extension possible. Followed aspects should be covered: > # Interface of the plugin (draft could be found in parent ticket) > # Interface to implement by relational nodes. Looks like we have to use > IgniteRel here, but it comes at cost of lost validation: IgniteConvention > uses this interface to validate the convention is set for proper rel. Need to > think about this. > # Interface of the schema. In the prototype the > org.apache.calcite.schema.SchemaPlus is used, but it doesn't look as a good > decision. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-15289) Collect global statistics
[ https://issues.apache.org/jira/browse/IGNITE-15289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17442593#comment-17442593 ] Alexander Belyak commented on IGNITE-15289: --- Fixed. > Collect global statistics > - > > Key: IGNITE-15289 > URL: https://issues.apache.org/jira/browse/IGNITE-15289 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Alexander Belyak >Assignee: Alexander Belyak >Priority: Major > Time Spent: 6h 50m > Remaining Estimate: 0h > > Collect global statistics by request to use in Calcite cost model. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-15128) Take own control of SQL functions
[ https://issues.apache.org/jira/browse/IGNITE-15128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17442440#comment-17442440 ] Konstantin Orlov commented on IGNITE-15128: --- [~alex_pl], the patch looks good to me except a few minors. Feel free to ignore them and merge the patch as is. > Take own control of SQL functions > - > > Key: IGNITE-15128 > URL: https://issues.apache.org/jira/browse/IGNITE-15128 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Aleksey Plekhanov >Priority: Major > Labels: calcite2-required, calcite3-required > Time Spent: 20m > Remaining Estimate: 0h > > As of now, we use a set of 4 database function dialects: > SqlLibrary.STANDARD, > SqlLibrary.POSTGRESQL, > SqlLibrary.ORACLE, > SqlLibrary.MYSQL > Seems we should have owned our dialect with a subset of the aforementioned > functions and have the ability to modify already exists functions and add a > new one. > During implementation need to sort out similar functions and choose just one > of them to avoid duplication, > See : > org.apache.calcite.util.BuiltInMethod > org.apache.calcite.sql.fun.SqlLibraryOperators > org.apache.calcite.runtime.SqlFunctions > org.apache.ignite.internal.processors.query.calcite.exec.exp.RexImpTable -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-14827) Calcite engine. Support of user defined function
[
https://issues.apache.org/jira/browse/IGNITE-14827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17442413#comment-17442413
]
Konstantin Orlov commented on IGNITE-14827:
---
[~alex_pl], I've left a comment in the PR. Please take a look.
> Calcite engine. Support of user defined function
>
>
> Key: IGNITE-14827
> URL: https://issues.apache.org/jira/browse/IGNITE-14827
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite2-required, calcite3-required
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Support of user-defined scalar function should be added. See
> {{CacheConfiguration#setSqlFunctionClasses}} and {{QuerySqlFunction}}
> annotation for details about current implementation in H2 engine.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-15905) IgniteClientSpringCacheManagerTest.testCacheManagerXmlConfiguration is flaky
[ https://issues.apache.org/jira/browse/IGNITE-15905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17442412#comment-17442412 ] Mikhail Petrov commented on IGNITE-15905: - [~NSAmelchev] Thank you for the review. > IgniteClientSpringCacheManagerTest.testCacheManagerXmlConfiguration is flaky > > > Key: IGNITE-15905 > URL: https://issues.apache.org/jira/browse/IGNITE-15905 > Project: Ignite > Issue Type: Test >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15885) Create and implement SortedIndexStorage based on RocksDB
[
https://issues.apache.org/jira/browse/IGNITE-15885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-15885:
-
Description:
h1. API
* Add {{SortedIndexStorage}} interface:
{code:java}
public interface SortedIndexStorage {
/** Index ID. */
IgniteUuid id();
/** Index configuration. */
TableIndexView configuration();
/** Schema of the index keys. */
SchemaDescriptor schema();
/** Retrieves the key of a partition storage for the given index key. */
SearchRow get(IndexKey row);
/** Adds the given row to the index */
void put(IndexKey row);
/** Removes the given row from the index. */
void remove(IndexKey row);
/** Replaces the {@code oldRow} with the {@code newRow}. */
void replace(IndexKey oldRow, IndexKey newRow);
/** Returns a range of index rows as specified in IEP-74. */
Cursor range(SearchKey lowerBound, SearchKey upperBound, byte
options);
}
{code}
* {{SearchKey}} can contain a smaller number of columns, than the {{IndexKey}},
needed for the prefix search.
{code:java}
public interface IndexKey {
byte[] asBytes();
}
public interface SearchKey {
byte[] asBytes();
}
{code}
* {{SearchRow}} is a class from the {{storage-api}} that represents a key from
the partition storage.
h1. Implementation details
For the initial implementation it is suggested to use {{BinaryRow}}
serialization mechanism (it is proposed to implement the {{IndexKey}} on top of
it, simply ignoring the value bytes) to store it in RocksDB. First
implementation will also use a naive comparator, that will convert each
{{BinaryRow}} into a {{Row}} and compare individual deserialized columns.
It is also proposed to store partition storage keys as values in the index
storage.
was:
h1. API
* Add {{SortedIndexStorage}} interface:
{code:java}
public interface SortedIndexStorage {
/** Index ID. */
IgniteUuid id();
/** Index configuration. */
TableIndexView configuration();
/** Schema of the index keys. */
SchemaDescriptor schema();
/** Retrieves the key of a partition storage for the given index key. */
SearchRow get(IndexKey row);
/** Adds the given row to the index */
void put(IndexKey row);
/** Removes the given row from the index. */
void remove(IndexKey row);
/** Replaces the {@code oldRow} with the {@code newRow}. */
void replace(IndexKey oldRow, IndexKey newRow);
/** Returns a range of index rows as specified in IEP-74. */
Cursor range(SearchKey lowerBound, SearchKey upperBound, byte
options);
}
{code}
* {{SearchKey}} can contain a smaller number of columns, than the {{IndexKey}},
needed for the prefix search.
{code:java}
public interface IndexKey {
byte[] asBytes();
}
public interface SearchKey {
byte[] asBytes();
}
{code}
* {{SearchRow}} is a class from the {{storage-api}} that represents a key from
the partition storage.
h1. Implementation details
For the initial implementation it is suggested to use {{BinaryRow}}
serialization mechanism (it is proposed to implement the {{IndexKey}} on top of
it, simply ignoring the value bytes) to store it in RocksDB. First
implementation will also use a naive comparator, that will convert each
{{BinaryRow}} into a {{Row}} and compare individual deserialized columns.
> Create and implement SortedIndexStorage based on RocksDB
>
>
> Key: IGNITE-15885
> URL: https://issues.apache.org/jira/browse/IGNITE-15885
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
>
> h1. API
> * Add {{SortedIndexStorage}} interface:
> {code:java}
> public interface SortedIndexStorage {
> /** Index ID. */
> IgniteUuid id();
>
> /** Index configuration. */
> TableIndexView configuration();
>
> /** Schema of the index keys. */
> SchemaDescriptor schema();
>
> /** Retrieves the key of a partition storage for the given index key. */
> SearchRow get(IndexKey row);
>
> /** Adds the given row to the index */
> void put(IndexKey row);
>
> /** Removes the given row from the index. */
> void remove(IndexKey row);
>
> /** Replaces the {@code oldRow} with the {@code newRow}. */
> void replace(IndexKey oldRow, IndexKey newRow);
>
> /** Returns a range of index rows as specified in IEP-74. */
> Cursor range(SearchKey lowerBound, SearchKey upperBound, byte
> options);
> }
> {code}
> * {{SearchKey}} can contain a smaller number of columns, than the
> {{IndexKey}}, needed for the prefix search.
> {code:java}
> public interface IndexKey {
> byte[] asBytes
[jira] [Resolved] (IGNITE-14928) Create Index entities
[
https://issues.apache.org/jira/browse/IGNITE-14928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev resolved IGNITE-14928.
--
Resolution: Invalid
> Create Index entities
> -
>
> Key: IGNITE-14928
> URL: https://issues.apache.org/jira/browse/IGNITE-14928
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Taras Ledkov
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
>
> The index storage requires the following new entities:
> # {{IndexKey}} - to serve as a key in the index storage and as a search
> parameter in queries. It should be serializable into a byte array, but not
> necessarily deserializable. Some of the columns included in the key can be
> omitted for range queries support.
> # {{IndexValue}} - to serve as a value in the index storage and as a result
> from the queries.
> # {{IndexSchema}} - to serve as a descriptor for (de-)serializing IndexKeys
> and IndexValues.
> The whole concept is similar to the {{BinaryRow}} but requires a different
> serialization protocol (e.g. no schema version and no key/value separation),
> but it should be possible to reuse some classes from the {{ignite-schema}}
> module.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15885) Create and implement SortedIndexStorage based on RocksDB
[
https://issues.apache.org/jira/browse/IGNITE-15885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-15885:
-
Description:
h1. API
* Add {{SortedIndexStorage}} interface:
{code:java}
public interface SortedIndexStorage {
/** Index ID. */
IgniteUuid id();
/** Index configuration. */
TableIndexView configuration();
/** Schema of the index keys. */
SchemaDescriptor schema();
/** Retrieves the key of a partition storage for the given index key. */
SearchRow get(IndexKey row);
/** Adds the given row to the index */
void put(IndexKey row);
/** Removes the given row from the index. */
void remove(IndexKey row);
/** Replaces the {@code oldRow} with the {@code newRow}. */
void replace(IndexKey oldRow, IndexKey newRow);
/** Returns a range of index rows as specified in IEP-74. */
Cursor range(SearchKey lowerBound, SearchKey upperBound, byte
options);
}
{code}
* {{SearchKey}} can contain a smaller number of columns, than the {{IndexKey}},
needed for the prefix search.
{code:java}
public interface IndexKey {
byte[] asBytes();
}
public interface SearchKey {
byte[] asBytes();
}
{code}
* {{SearchRow}} is a class from the {{storage-api}} that represents a key from
the partition storage.
h1. Implementation details
For the initial implementation it is suggested to use {{BinaryRow}}
serialization mechanism (it is proposed to implement the {{IndexKey}} on top of
it, simply ignoring the value bytes) to store it in RocksDB. First
implementation will also use a naive comparator, that will convert each
{{BinaryRow}} into a {{Row}} and compare individual deserialized columns.
was:
# Add {{SortedIndexStorage}} interface:
{code:java}
public interface SortedIndexStorage {
/** Index ID. */
IgniteUuid id();
/** Index configuration. */
TableIndexView configuration();
/** Schema of the index keys. */
SchemaDescriptor schema();
/** Retrieves the key of a partition storage for the given index key. */
SearchRow get(IndexKey row);
/** Adds the given row to the index */
void put(IndexKey row);
/** Removes the given row from the index. */
void remove(IndexKey row);
/** Replaces the {@code oldRow} with the {@code newRow}. */
void replace(IndexKey oldRow, IndexKey newRow);
/** Returns a range of index rows as specified in IEP-74. */
Cursor range(SearchKey lowerBound, SearchKey upperBound, byte
options);
}
{code}
> Create and implement SortedIndexStorage based on RocksDB
>
>
> Key: IGNITE-15885
> URL: https://issues.apache.org/jira/browse/IGNITE-15885
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
>
> h1. API
> * Add {{SortedIndexStorage}} interface:
> {code:java}
> public interface SortedIndexStorage {
> /** Index ID. */
> IgniteUuid id();
>
> /** Index configuration. */
> TableIndexView configuration();
>
> /** Schema of the index keys. */
> SchemaDescriptor schema();
>
> /** Retrieves the key of a partition storage for the given index key. */
> SearchRow get(IndexKey row);
>
> /** Adds the given row to the index */
> void put(IndexKey row);
>
> /** Removes the given row from the index. */
> void remove(IndexKey row);
>
> /** Replaces the {@code oldRow} with the {@code newRow}. */
> void replace(IndexKey oldRow, IndexKey newRow);
>
> /** Returns a range of index rows as specified in IEP-74. */
> Cursor range(SearchKey lowerBound, SearchKey upperBound, byte
> options);
> }
> {code}
> * {{SearchKey}} can contain a smaller number of columns, than the
> {{IndexKey}}, needed for the prefix search.
> {code:java}
> public interface IndexKey {
> byte[] asBytes();
> }
> public interface SearchKey {
> byte[] asBytes();
> }
> {code}
> * {{SearchRow}} is a class from the {{storage-api}} that represents a key
> from the partition storage.
> h1. Implementation details
> For the initial implementation it is suggested to use {{BinaryRow}}
> serialization mechanism (it is proposed to implement the {{IndexKey}} on top
> of it, simply ignoring the value bytes) to store it in RocksDB. First
> implementation will also use a naive comparator, that will convert each
> {{BinaryRow}} into a {{Row}} and compare individual deserialized columns.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15885) Create and implement SortedIndexStorage based on RocksDB
[
https://issues.apache.org/jira/browse/IGNITE-15885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-15885:
-
Description:
# Add {{SortedIndexStorage}} interface:
{code:java}
public interface SortedIndexStorage {
/** Index ID. */
IgniteUuid id();
/** Index configuration. */
TableIndexView configuration();
/** Schema of the index keys. */
SchemaDescriptor schema();
/** Retrieves the key of a partition storage for the given index key. */
SearchRow get(IndexKey row);
/** Adds the given row to the index */
void put(IndexKey row);
/** Removes the given row from the index. */
void remove(IndexKey row);
/** Replaces the {@code oldRow} with the {@code newRow}. */
void replace(IndexKey oldRow, IndexKey newRow);
/** Returns a range of index rows as specified in IEP-74. */
Cursor range(SearchKey lowerBound, SearchKey upperBound, byte
options);
}
{code}
was:
# Add {{SortedIndexStorage}} interface:
{code:java}
public interface SortedIndexStorage {
/** Index ID. */
IgniteUuid id();
/** Index configuration. */
TableIndexView configuration();
/** Schema of the index keys. */
IndexSchema schema();
/** Adds the given row to the index */
void put(IndexKey row);
/** Removes the given row from the index. */
void remove(IndexKey row);
/** Replaces the {@code oldRow} with {@code newRow}. */
void replace(IndexKey oldRow, IndexKey newRow);
/** Returns a range of index rows as specified in IEP-74. */
Cursor range(IndexKey lowerBound, IndexKey upperBound, byte
scanBoundMask, BitSet includedColumns);
}
{code}
> Create and implement SortedIndexStorage based on RocksDB
>
>
> Key: IGNITE-15885
> URL: https://issues.apache.org/jira/browse/IGNITE-15885
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
>
> # Add {{SortedIndexStorage}} interface:
> {code:java}
> public interface SortedIndexStorage {
> /** Index ID. */
> IgniteUuid id();
>
> /** Index configuration. */
> TableIndexView configuration();
>
> /** Schema of the index keys. */
> SchemaDescriptor schema();
>
> /** Retrieves the key of a partition storage for the given index key. */
> SearchRow get(IndexKey row);
>
> /** Adds the given row to the index */
> void put(IndexKey row);
>
> /** Removes the given row from the index. */
> void remove(IndexKey row);
>
> /** Replaces the {@code oldRow} with the {@code newRow}. */
> void replace(IndexKey oldRow, IndexKey newRow);
>
> /** Returns a range of index rows as specified in IEP-74. */
> Cursor range(SearchKey lowerBound, SearchKey upperBound, byte
> options);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15906) JDK17 - Could not initialize class org.apache.ignite.internal.util.IgniteUtils
[
https://issues.apache.org/jira/browse/IGNITE-15906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Weber updated IGNITE-15906:
Description:
When attempting to use JDK17 with Ignite 2.11, an exception is now thrown.
{code:java}
java.lang.NoClassDefFoundError: Could not initialize class
org.apache.ignite.internal.util.IgniteUtils
at
org.apache.ignite.spi.IgniteSpiAdapter.(IgniteSpiAdapter.java:122)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.(TcpDiscoverySpi.java:241){code}
was:
When attempting to use JDK17 with Ignite 2.11, an exception is now thrown.
{code:java}
java.lang.NoClassDefFoundError: Could not initialize class
org.apache.ignite.internal.util.IgniteUtils at
org.apache.ignite.spi.IgniteSpiAdapter.(IgniteSpiAdapter.java:122) at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.(TcpDiscoverySpi.java:241){code}
> JDK17 - Could not initialize class org.apache.ignite.internal.util.IgniteUtils
> --
>
> Key: IGNITE-15906
> URL: https://issues.apache.org/jira/browse/IGNITE-15906
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.11
>Reporter: Mike Weber
>Priority: Major
>
> When attempting to use JDK17 with Ignite 2.11, an exception is now thrown.
>
> {code:java}
> java.lang.NoClassDefFoundError: Could not initialize class
> org.apache.ignite.internal.util.IgniteUtils
> at
> org.apache.ignite.spi.IgniteSpiAdapter.(IgniteSpiAdapter.java:122)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.(TcpDiscoverySpi.java:241){code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-15906) JDK17 - Could not initialize class org.apache.ignite.internal.util.IgniteUtils
Mike Weber created IGNITE-15906:
---
Summary: JDK17 - Could not initialize class
org.apache.ignite.internal.util.IgniteUtils
Key: IGNITE-15906
URL: https://issues.apache.org/jira/browse/IGNITE-15906
Project: Ignite
Issue Type: Bug
Affects Versions: 2.11
Reporter: Mike Weber
When attempting to use JDK17 with Ignite 2.11, an exception is now thrown.
{code:java}
java.lang.NoClassDefFoundError: Could not initialize class
org.apache.ignite.internal.util.IgniteUtils at
org.apache.ignite.spi.IgniteSpiAdapter.(IgniteSpiAdapter.java:122) at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.(TcpDiscoverySpi.java:241){code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-15905) IgniteClientSpringCacheManagerTest.testCacheManagerXmlConfiguration is flaky
Mikhail Petrov created IGNITE-15905: --- Summary: IgniteClientSpringCacheManagerTest.testCacheManagerXmlConfiguration is flaky Key: IGNITE-15905 URL: https://issues.apache.org/jira/browse/IGNITE-15905 Project: Ignite Issue Type: Test Reporter: Mikhail Petrov Assignee: Mikhail Petrov -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15771) Sort out and merge Calcite tickets to Ignite 3.0
[ https://issues.apache.org/jira/browse/IGNITE-15771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-15771: -- Description: Let's sort out tikets contains by [filter|https://issues.apache.org/jira/issues/?jql=project%3DIgnite%20and%20labels%20in(calcite3-required)%20and%20labels%20not%20in(calcite2-required)%20order%20by%20resolutiondate%20ASC]. Tickets that could be simply merged - merge immediately. For hard cases let's create separate tickets with estimation and link them to IGNITE-15658 or links to blocker ticket. Tickets to bulk merge: - IGNITE-14807; - IGNITE-14594; - IGNITE-14589; - IGNITE-13159; - IGNITE-15127; - IGNITE-15031; - IGNITE-14816; - IGNITE-13136; - IGNITE-15203; - IGNITE-15002; - IGNITE-14749; - IGNITE-14597; was: Let's sort out tikets contains by [filter|https://issues.apache.org/jira/issues/?jql=project%3DIgnite%20and%20labels%20in(calcite3-required)%20and%20labels%20not%20in(calcite2-required)%20order%20by%20resolutiondate%20ASC]. Tickets that could be simply merged - merge immediately. For hard cases let's create separate tickets with estimation and link them to IGNITE-15658 or links to blocker ticket. Tickets to bulk merge: - IGNITE-14807; - IGNITE-14594; - IGNITE-14589; - IGNITE-13159; - IGNITE-15127; - IGNITE-15031; - IGNITE-14816; - IGNITE-13136; - IGNITE-15203; - IGNITE-15002; - IGNITE-14749; > Sort out and merge Calcite tickets to Ignite 3.0 > > > Key: IGNITE-15771 > URL: https://issues.apache.org/jira/browse/IGNITE-15771 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Taras Ledkov >Priority: Major > Labels: ignite-3 > > Let's sort out tikets contains by > [filter|https://issues.apache.org/jira/issues/?jql=project%3DIgnite%20and%20labels%20in(calcite3-required)%20and%20labels%20not%20in(calcite2-required)%20order%20by%20resolutiondate%20ASC]. > Tickets that could be simply merged - merge immediately. For hard cases > let's create separate tickets with estimation and link them to IGNITE-15658 > or links to blocker ticket. > Tickets to bulk merge: > - IGNITE-14807; > - IGNITE-14594; > - IGNITE-14589; > - IGNITE-13159; > - IGNITE-15127; > - IGNITE-15031; > - IGNITE-14816; > - IGNITE-13136; > - IGNITE-15203; > - IGNITE-15002; > - IGNITE-14749; > - IGNITE-14597; -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15771) Sort out and merge Calcite tickets to Ignite 3.0
[ https://issues.apache.org/jira/browse/IGNITE-15771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-15771: -- Description: Let's sort out tikets contains by [filter|https://issues.apache.org/jira/issues/?jql=project%3DIgnite%20and%20labels%20in(calcite3-required)%20and%20labels%20not%20in(calcite2-required)%20order%20by%20resolutiondate%20ASC]. Tickets that could be simply merged - merge immediately. For hard cases let's create separate tickets with estimation and link them to IGNITE-15658 or links to blocker ticket. Tickets to bulk merge: - IGNITE-14807; - IGNITE-14594; - IGNITE-14589; - IGNITE-13159; - IGNITE-15127; - IGNITE-15031; - IGNITE-14816; - IGNITE-13136; - IGNITE-15203; - IGNITE-15002; - IGNITE-14749; was: Let's sort out tikets contains by [filter|https://issues.apache.org/jira/issues/?jql=project%3DIgnite%20and%20labels%20in(calcite3-required)%20and%20labels%20not%20in(calcite2-required)%20order%20by%20resolutiondate%20ASC]. Tickets that could be simply merged - merge immediately. For hard cases let's create separate tickets with estimation and link them to IGNITE-15658 or links to blocker ticket. Tickets to bulk merge: - IGNITE-14807; - IGNITE-14594; - IGNITE-14589; - IGNITE-13159; - IGNITE-15127; - IGNITE-15031; - IGNITE-14816; - IGNITE-13136; - IGNITE-15203; - IGNITE-15002; > Sort out and merge Calcite tickets to Ignite 3.0 > > > Key: IGNITE-15771 > URL: https://issues.apache.org/jira/browse/IGNITE-15771 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Taras Ledkov >Priority: Major > Labels: ignite-3 > > Let's sort out tikets contains by > [filter|https://issues.apache.org/jira/issues/?jql=project%3DIgnite%20and%20labels%20in(calcite3-required)%20and%20labels%20not%20in(calcite2-required)%20order%20by%20resolutiondate%20ASC]. > Tickets that could be simply merged - merge immediately. For hard cases > let's create separate tickets with estimation and link them to IGNITE-15658 > or links to blocker ticket. > Tickets to bulk merge: > - IGNITE-14807; > - IGNITE-14594; > - IGNITE-14589; > - IGNITE-13159; > - IGNITE-15127; > - IGNITE-15031; > - IGNITE-14816; > - IGNITE-13136; > - IGNITE-15203; > - IGNITE-15002; > - IGNITE-14749; -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15669) Get rid of leakage of Calcite classes through SqlCursor class
[ https://issues.apache.org/jira/browse/IGNITE-15669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-15669: -- Labels: ignite-3 (was: calcite3-required ignite-3) > Get rid of leakage of Calcite classes through SqlCursor class > - > > Key: IGNITE-15669 > URL: https://issues.apache.org/jira/browse/IGNITE-15669 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Taras Ledkov >Priority: Major > Labels: ignite-3 > Time Spent: 0.5h > Remaining Estimate: 0h > > As of now org.apache.ignite.internal.processors.query.calcite.SqlCursor > exposing FieldsMetadata which use calcite internal class RelDataType. So we > have leakagу of Calcite classes outside of calcite module. Need to fix it. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-15904) [Ignite Website] Update for events schedule
Kseniya Romanova created IGNITE-15904: - Summary: [Ignite Website] Update for events schedule Key: IGNITE-15904 URL: https://issues.apache.org/jira/browse/IGNITE-15904 Project: Ignite Issue Type: Task Reporter: Kseniya Romanova Please update the [https://ignite.apache.org/events.html] page with new event: Apache Ignite with CDC now Podlodka Conference, Nikolay Izhikov November 11, 2021 Nikolay will tell, what is Change Data Capture, why is it needed, and how CDC is done in Apache Ignite. Read more = [https://podlodka.io/becrew] Also, please change the top line for: Apache Ignite 3.0 Alpha 3: learn what's new [https://ignite.apache.org/docs/3.0.0-alpha] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-15904) [Ignite Website] Update for events schedule
[ https://issues.apache.org/jira/browse/IGNITE-15904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kseniya Romanova reassigned IGNITE-15904: - Assignee: Mauricio Stekl > [Ignite Website] Update for events schedule > --- > > Key: IGNITE-15904 > URL: https://issues.apache.org/jira/browse/IGNITE-15904 > Project: Ignite > Issue Type: Task >Reporter: Kseniya Romanova >Assignee: Mauricio Stekl >Priority: Trivial > > Please update the [https://ignite.apache.org/events.html] page with new event: > Apache Ignite with CDC now > Podlodka Conference, Nikolay Izhikov > November 11, 2021 > Nikolay will tell, what is Change Data Capture, why is it needed, and how CDC > is done in Apache Ignite. > Read more = [https://podlodka.io/becrew] > Also, please change the top line for: > Apache Ignite 3.0 Alpha 3: learn what's new > [https://ignite.apache.org/docs/3.0.0-alpha] > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-15901) Drop Live schema support.
[ https://issues.apache.org/jira/browse/IGNITE-15901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reassigned IGNITE-15901: - Assignee: Andrey Mashenkov > Drop Live schema support. > - > > Key: IGNITE-15901 > URL: https://issues.apache.org/jira/browse/IGNITE-15901 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Labels: iep-54, ignite-3 > Fix For: 3.0.0-alpha4 > > Time Spent: 10m > Remaining Estimate: 0h > > h3. Motivation. > The Live-schema concept looks like a very disputable thing. It may cause > unwanted schema change if a new/outdated/broken client puts the data to the > grid. Implicit schema changes may lead to unpredicted behaviour from the user > perspective. > In most cases, user application and schema are mutually dependent things. > Thus, the application model and schema must be changed consistently. > In the general case, it is impossible to keep the consistency and the > decision on that must be taken on the user side. > Actually, there are 2 different use cases for the schema-last approach: > * The first one, when a user creates a table without specifying a schema and > Ignite automatically create the initial schema version on the first 'put' > operation. This may be useful for PoC or tests. > * The second one, when a user changes data model classes, and Ignite update > the schema implicitly on the next 'put' operation to make schema match the > new data model. Here are many limitations we can do transparently without any > additional configuration from the user side. > Thus, the first case may be a not too bad idea. However, the second case > looks error-prone. > h3. Suggestion. > Drop LiveSchema mode and remove all the related code. > Postpone all the related tasks unless we will have clear explanation on how > it should work and how a user should use it. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15771) Sort out and merge Calcite tickets to Ignite 3.0
[ https://issues.apache.org/jira/browse/IGNITE-15771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-15771: -- Description: Let's sort out tikets contains by [filter|https://issues.apache.org/jira/issues/?jql=project%3DIgnite%20and%20labels%20in(calcite3-required)%20and%20labels%20not%20in(calcite2-required)%20order%20by%20resolutiondate%20ASC]. Tickets that could be simply merged - merge immediately. For hard cases let's create separate tickets with estimation and link them to IGNITE-15658 or links to blocker ticket. Tickets to bulk merge: - IGNITE-14807; - IGNITE-14594; - IGNITE-14589; - IGNITE-13159; - IGNITE-15127; - IGNITE-15031; - IGNITE-14816; - IGNITE-13136; - IGNITE-15203; - IGNITE-15002; was: Let's sort out tikets contains by [filter|https://issues.apache.org/jira/issues/?jql=project%3DIgnite%20and%20labels%20in(calcite3-required)%20and%20labels%20not%20in(calcite2-required)%20order%20by%20resolutiondate%20ASC]. Tickets that could be simply merged - merge immediately. For hard cases let's create separate tickets with estimation and link them to IGNITE-15658 or links to blocker ticket. Tickets to bulk merge: - IGNITE-14807; - IGNITE-14594; - IGNITE-14589; - IGNITE-13159; - IGNITE-15127; - IGNITE-15031; - IGNITE-14816; - IGNITE-13136; - IGNITE-15203; > Sort out and merge Calcite tickets to Ignite 3.0 > > > Key: IGNITE-15771 > URL: https://issues.apache.org/jira/browse/IGNITE-15771 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Taras Ledkov >Priority: Major > Labels: ignite-3 > > Let's sort out tikets contains by > [filter|https://issues.apache.org/jira/issues/?jql=project%3DIgnite%20and%20labels%20in(calcite3-required)%20and%20labels%20not%20in(calcite2-required)%20order%20by%20resolutiondate%20ASC]. > Tickets that could be simply merged - merge immediately. For hard cases > let's create separate tickets with estimation and link them to IGNITE-15658 > or links to blocker ticket. > Tickets to bulk merge: > - IGNITE-14807; > - IGNITE-14594; > - IGNITE-14589; > - IGNITE-13159; > - IGNITE-15127; > - IGNITE-15031; > - IGNITE-14816; > - IGNITE-13136; > - IGNITE-15203; > - IGNITE-15002; -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (IGNITE-15873) Fix constructor argument in jetty config threadPool -> threadpool
[
https://issues.apache.org/jira/browse/IGNITE-15873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17441764#comment-17441764
]
Vyacheslav Koptilin edited comment on IGNITE-15873 at 11/11/21, 1:05 PM:
-
Hope that the example will be updated soon as well
https://ignite.apache.org/docs/latest/restapi#example-jetty-xml-configuration
was (Author: slava.koptilin):
Hope that the example will updated soon as well
https://ignite.apache.org/docs/latest/restapi#example-jetty-xml-configuration
> Fix constructor argument in jetty config threadPool -> threadpool
> -
>
> Key: IGNITE-15873
> URL: https://issues.apache.org/jira/browse/IGNITE-15873
> Project: Ignite
> Issue Type: Bug
> Components: documentation
>Affects Versions: 2.11
>Reporter: Ilya Korol
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.13
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> According to jetty sources:
> {code:java}
> public Server(@Name("threadpool") ThreadPool pool)
> {
> _threadPool = pool != null ? pool : new QueuedThreadPool();
> addBean(_threadPool);
> setServer(this);
> }
> {code}
> When we instantiate Server class via xml we need to use *threadpool* (all
> lowercase) instead of *threadPool*
> {code:java}
>
> ---
> +++
> ...
> {code}
> otherwise we would get an error:
> {code:java}
> Caused by: java.lang.IllegalStateException: No matching constructor class
> org.eclipse.jetty.server.Server in file:///...config/jetty.xml
> at
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.configure(XmlConfiguration.java:454)
> at
> org.eclipse.jetty.xml.XmlConfiguration.configure(XmlConfiguration.java:380)
> at
> org.apache.ignite.internal.processors.rest.protocols.http.jetty.GridJettyRestProtocol.loadJettyConfiguration(GridJettyRestProtocol.java:318)
> ... 16 more
> {code}
> [SO
> issue|https://stackoverflow.com/questions/69859238/apache-ignite-unable-to-start-2-11-ignite-nodes-in-a-cluster]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15901) Drop Live schema support.
[ https://issues.apache.org/jira/browse/IGNITE-15901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-15901: -- Component/s: sql > Drop Live schema support. > - > > Key: IGNITE-15901 > URL: https://issues.apache.org/jira/browse/IGNITE-15901 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Andrey Mashenkov >Priority: Major > Labels: iep-54, ignite-3 > Fix For: 3.0.0-alpha4 > > Time Spent: 10m > Remaining Estimate: 0h > > h3. Motivation. > The Live-schema concept looks like a very disputable thing. It may cause > unwanted schema change if a new/outdated/broken client puts the data to the > grid. Implicit schema changes may lead to unpredicted behaviour from the user > perspective. > In most cases, user application and schema are mutually dependent things. > Thus, the application model and schema must be changed consistently. > In the general case, it is impossible to keep the consistency and the > decision on that must be taken on the user side. > Actually, there are 2 different use cases for the schema-last approach: > * The first one, when a user creates a table without specifying a schema and > Ignite automatically create the initial schema version on the first 'put' > operation. This may be useful for PoC or tests. > * The second one, when a user changes data model classes, and Ignite update > the schema implicitly on the next 'put' operation to make schema match the > new data model. Here are many limitations we can do transparently without any > additional configuration from the user side. > Thus, the first case may be a not too bad idea. However, the second case > looks error-prone. > h3. Suggestion. > Drop LiveSchema mode and remove all the related code. > Postpone all the related tasks unless we will have clear explanation on how > it should work and how a user should use it. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15771) Sort out and merge Calcite tickets to Ignite 3.0
[ https://issues.apache.org/jira/browse/IGNITE-15771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-15771: -- Description: Let's sort out tikets contains by [filter|https://issues.apache.org/jira/issues/?jql=project%3DIgnite%20and%20labels%20in(calcite3-required)%20and%20labels%20not%20in(calcite2-required)%20order%20by%20resolutiondate%20ASC]. Tickets that could be simply merged - merge immediately. For hard cases let's create separate tickets with estimation and link them to IGNITE-15658 or links to blocker ticket. Tickets to bulk merge: - IGNITE-14807; - IGNITE-14594; - IGNITE-14589; - IGNITE-13159; - IGNITE-15127; - IGNITE-15031; - IGNITE-14816; - IGNITE-13136; - IGNITE-15203; was: Let's sort out tikets contains by [filter|https://issues.apache.org/jira/issues/?jql=project%3DIgnite%20and%20labels%20in(calcite3-required)%20and%20labels%20not%20in(calcite2-required)%20order%20by%20resolutiondate%20ASC]. Tickets that could be simply merged - merge immediately. For hard cases let's create separate tickets with estimation and link them to IGNITE-15658 or links to blocker ticket. Tickets to bulk merge: - IGNITE-14807; - IGNITE-14594; - IGNITE-14589; - IGNITE-13159; - IGNITE-15127; - IGNITE-15031; - IGNITE-14816; - IGNITE-13136; > Sort out and merge Calcite tickets to Ignite 3.0 > > > Key: IGNITE-15771 > URL: https://issues.apache.org/jira/browse/IGNITE-15771 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Taras Ledkov >Priority: Major > Labels: ignite-3 > > Let's sort out tikets contains by > [filter|https://issues.apache.org/jira/issues/?jql=project%3DIgnite%20and%20labels%20in(calcite3-required)%20and%20labels%20not%20in(calcite2-required)%20order%20by%20resolutiondate%20ASC]. > Tickets that could be simply merged - merge immediately. For hard cases > let's create separate tickets with estimation and link them to IGNITE-15658 > or links to blocker ticket. > Tickets to bulk merge: > - IGNITE-14807; > - IGNITE-14594; > - IGNITE-14589; > - IGNITE-13159; > - IGNITE-15127; > - IGNITE-15031; > - IGNITE-14816; > - IGNITE-13136; > - IGNITE-15203; -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15901) Drop Live schema support.
[ https://issues.apache.org/jira/browse/IGNITE-15901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-15901: -- Description: h3. Motivation. The Live-schema concept looks like a very disputable thing. It may cause unwanted schema change if a new/outdated/broken client puts the data to the grid. Implicit schema changes may lead to unpredicted behaviour from the user perspective. In most cases, user application and schema are mutually dependent things. Thus, the application model and schema must be changed consistently. In the general case, it is impossible to keep the consistency and the decision on that must be taken on the user side. Actually, there are 2 different use cases for the schema-last approach: * The first one, when a user creates a table without specifying a schema and Ignite automatically create the initial schema version on the first 'put' operation. This may be useful for PoC or tests. * The second one, when a user changes data model classes, and Ignite update the schema implicitly on the next 'put' operation to make schema match the new data model. Here are many limitations we can do transparently without any additional configuration from the user side. Thus, the first case may be a not too bad idea. However, the second case looks error-prone. h3. Suggestion. Drop LiveSchema mode and remove all the related code. Postpone all the related tasks unless we will have clear explanation on how it should work and how a user should use it. was: h3. Motivation. The Live-schema concept looks like a very disputable thing. It may cause unwanted schema change if a new/outdated/broken client puts the data to the grid. Implicit schema changes may lead to unpredicted behaviour from the user perspective. In most cases, user application and schema are mutually dependent things. Thus, the application model and schema must be changed consistently. In the general case, it is impossible to keep the consistency and the decision on that must be taken on the user side. Actually, there are 2 different use cases for the schema-last approach: * The first one, when a user creates a table without specifying a schema and Ignite automatically create the initial schema version on the first 'put' operation. This may be useful for PoC or tests. * The second one, when a user changes data model classes, and Ignite update the schema implicitly on the next 'put' operation to make schema match the new data model. Here are many limitations we can do transparently without any additional configuration from the user side. Thus, the first case may be a not too bad idea. However, the second case looks error-prone. h3. Suggestion. Drop LiveSchema mode and remove all the code related to this unless we will clear explanation on how it should work and how a user should use it. > Drop Live schema support. > - > > Key: IGNITE-15901 > URL: https://issues.apache.org/jira/browse/IGNITE-15901 > Project: Ignite > Issue Type: Bug >Reporter: Andrey Mashenkov >Priority: Major > Labels: iep-54, ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > h3. Motivation. > The Live-schema concept looks like a very disputable thing. It may cause > unwanted schema change if a new/outdated/broken client puts the data to the > grid. Implicit schema changes may lead to unpredicted behaviour from the user > perspective. > In most cases, user application and schema are mutually dependent things. > Thus, the application model and schema must be changed consistently. > In the general case, it is impossible to keep the consistency and the > decision on that must be taken on the user side. > Actually, there are 2 different use cases for the schema-last approach: > * The first one, when a user creates a table without specifying a schema and > Ignite automatically create the initial schema version on the first 'put' > operation. This may be useful for PoC or tests. > * The second one, when a user changes data model classes, and Ignite update > the schema implicitly on the next 'put' operation to make schema match the > new data model. Here are many limitations we can do transparently without any > additional configuration from the user side. > Thus, the first case may be a not too bad idea. However, the second case > looks error-prone. > h3. Suggestion. > Drop LiveSchema mode and remove all the related code. > Postpone all the related tasks unless we will have clear explanation on how > it should work and how a user should use it. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-15903) Consistency recovery command (Read Repair via control.ch) should return 0 status only when everything is consistent.
Anton Vinogradov created IGNITE-15903: - Summary: Consistency recovery command (Read Repair via control.ch) should return 0 status only when everything is consistent. Key: IGNITE-15903 URL: https://issues.apache.org/jira/browse/IGNITE-15903 Project: Ignite Issue Type: Sub-task Reporter: Anton Vinogradov Assignee: Anton Vinogradov -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15901) Drop Live schema support.
[ https://issues.apache.org/jira/browse/IGNITE-15901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-15901: -- Fix Version/s: 3.0.0-alpha4 > Drop Live schema support. > - > > Key: IGNITE-15901 > URL: https://issues.apache.org/jira/browse/IGNITE-15901 > Project: Ignite > Issue Type: Bug >Reporter: Andrey Mashenkov >Priority: Major > Labels: iep-54, ignite-3 > Fix For: 3.0.0-alpha4 > > Time Spent: 10m > Remaining Estimate: 0h > > h3. Motivation. > The Live-schema concept looks like a very disputable thing. It may cause > unwanted schema change if a new/outdated/broken client puts the data to the > grid. Implicit schema changes may lead to unpredicted behaviour from the user > perspective. > In most cases, user application and schema are mutually dependent things. > Thus, the application model and schema must be changed consistently. > In the general case, it is impossible to keep the consistency and the > decision on that must be taken on the user side. > Actually, there are 2 different use cases for the schema-last approach: > * The first one, when a user creates a table without specifying a schema and > Ignite automatically create the initial schema version on the first 'put' > operation. This may be useful for PoC or tests. > * The second one, when a user changes data model classes, and Ignite update > the schema implicitly on the next 'put' operation to make schema match the > new data model. Here are many limitations we can do transparently without any > additional configuration from the user side. > Thus, the first case may be a not too bad idea. However, the second case > looks error-prone. > h3. Suggestion. > Drop LiveSchema mode and remove all the related code. > Postpone all the related tasks unless we will have clear explanation on how > it should work and how a user should use it. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-15902) Broken link in Ignite documentation
Mirza Aliev created IGNITE-15902: Summary: Broken link in Ignite documentation Key: IGNITE-15902 URL: https://issues.apache.org/jira/browse/IGNITE-15902 Project: Ignite Issue Type: Bug Components: documentation Reporter: Mirza Aliev Broken link in this section of documentation https://ignite.apache.org/docs/latest/monitoring-metrics/metrics#monitoring-data-center-replication Seems, that this section is not related to Ignite and should be removed. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-15901) Drop Live schema support.
Andrey Mashenkov created IGNITE-15901: - Summary: Drop Live schema support. Key: IGNITE-15901 URL: https://issues.apache.org/jira/browse/IGNITE-15901 Project: Ignite Issue Type: Bug Reporter: Andrey Mashenkov h3. Motivation. The Live-schema concept looks like a very disputable thing. It may cause unwanted schema change if a new/outdated/broken client puts the data to the grid. Implicit schema changes may lead to unpredicted behaviour from the user perspective. In most cases, user application and schema are mutually dependent things. Thus, the application model and schema must be changed consistently. In the general case, it is impossible to keep the consistency and the decision on that must be taken on the user side. Actually, there are 2 different use cases for the schema-last approach: * The first one, when a user creates a table without specifying a schema and Ignite automatically create the initial schema version on the first 'put' operation. This may be useful for PoC or tests. * The second one, when a user changes data model classes, and Ignite update the schema implicitly on the next 'put' operation to make schema match the new data model. Here are many limitations we can do transparently without any additional configuration from the user side. Thus, the first case may be a not too bad idea. However, the second case looks error-prone. h3. Suggestion. Drop LiveSchema mode and remove all the code related to this unless we will clear explanation on how it should work and how a user should use it. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15771) Sort out and merge Calcite tickets to Ignite 3.0
[ https://issues.apache.org/jira/browse/IGNITE-15771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-15771: -- Description: Let's sort out tikets contains by [filter|https://issues.apache.org/jira/issues/?jql=project%3DIgnite%20and%20labels%20in(calcite3-required)%20and%20labels%20not%20in(calcite2-required)%20order%20by%20resolutiondate%20ASC]. Tickets that could be simply merged - merge immediately. For hard cases let's create separate tickets with estimation and link them to IGNITE-15658 or links to blocker ticket. Tickets to bulk merge: - IGNITE-14807; - IGNITE-14594; - IGNITE-14589; - IGNITE-13159; - IGNITE-15127; - IGNITE-15031; - IGNITE-14816; - IGNITE-13136; was: Let's sort out tikets contains by [filter|https://issues.apache.org/jira/issues/?jql=project%3DIgnite%20and%20labels%20in(calcite3-required)%20and%20labels%20not%20in(calcite2-required)%20order%20by%20resolutiondate%20ASC]. Tickets that could be simply merged - merge immediately. For hard cases let's create separate tickets with estimation and link them to IGNITE-15658 or links to blocker ticket. Tickets to bulk merge: - IGNITE-14807; - IGNITE-14594; - IGNITE-14589; - IGNITE-13159; - IGNITE-15127; - IGNITE-15031; - IGNITE-14816; > Sort out and merge Calcite tickets to Ignite 3.0 > > > Key: IGNITE-15771 > URL: https://issues.apache.org/jira/browse/IGNITE-15771 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Taras Ledkov >Priority: Major > Labels: ignite-3 > > Let's sort out tikets contains by > [filter|https://issues.apache.org/jira/issues/?jql=project%3DIgnite%20and%20labels%20in(calcite3-required)%20and%20labels%20not%20in(calcite2-required)%20order%20by%20resolutiondate%20ASC]. > Tickets that could be simply merged - merge immediately. For hard cases > let's create separate tickets with estimation and link them to IGNITE-15658 > or links to blocker ticket. > Tickets to bulk merge: > - IGNITE-14807; > - IGNITE-14594; > - IGNITE-14589; > - IGNITE-13159; > - IGNITE-15127; > - IGNITE-15031; > - IGNITE-14816; > - IGNITE-13136; -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-15853) Add api description of polymorphic configuration to modules/configuration/README.md
[ https://issues.apache.org/jira/browse/IGNITE-15853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17442213#comment-17442213 ] Kirill Tkalenko commented on IGNITE-15853: -- [~ibessonov] Please make code review. > Add api description of polymorphic configuration to > modules/configuration/README.md > --- > > Key: IGNITE-15853 > URL: https://issues.apache.org/jira/browse/IGNITE-15853 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha4 > > Time Spent: 40m > Remaining Estimate: 0h > > Need to add a description of the api of the polymorphic configuration to the > *modules/configuration/README.md*, I forgot to do it in IGNITE-14645. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-15289) Collect global statistics
[ https://issues.apache.org/jira/browse/IGNITE-15289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17442195#comment-17442195 ] Konstantin Orlov commented on IGNITE-15289: --- [~Berkov], please fix styles. > Collect global statistics > - > > Key: IGNITE-15289 > URL: https://issues.apache.org/jira/browse/IGNITE-15289 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Alexander Belyak >Assignee: Alexander Belyak >Priority: Major > Time Spent: 6h 50m > Remaining Estimate: 0h > > Collect global statistics by request to use in Calcite cost model. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-15900) Disable javadoc style checks for test methods.
[ https://issues.apache.org/jira/browse/IGNITE-15900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reassigned IGNITE-15900: - Assignee: Andrey Mashenkov > Disable javadoc style checks for test methods. > -- > > Key: IGNITE-15900 > URL: https://issues.apache.org/jira/browse/IGNITE-15900 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > > As of now, missed javadocs are allowed for methods annotated with \@Test. > Let's make the same for parameterized tests \@TestFactory, \@ParameterizedTest > and methods annotated \@BeforeEach, \@AfterAll, \@AfterEach, \@AfterAll -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-15900) Disable javadoc style checks for test methods.
Andrey Mashenkov created IGNITE-15900: - Summary: Disable javadoc style checks for test methods. Key: IGNITE-15900 URL: https://issues.apache.org/jira/browse/IGNITE-15900 Project: Ignite Issue Type: Improvement Reporter: Andrey Mashenkov As of now, missed javadocs are allowed for methods annotated with \@Test. Let's make the same for parameterized tests \@TestFactory, \@ParameterizedTest and methods annotated \@BeforeEach, \@AfterAll, \@AfterEach, \@AfterAll -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-15377) [Ignite 3] Add config for IDEA with codestyle
[ https://issues.apache.org/jira/browse/IGNITE-15377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17442170#comment-17442170 ] Andrey Mashenkov commented on IGNITE-15377: --- [~agura], actually, I just want the assignee person would ensure a codestyle check passed after using IDEA autoformat. Now I feel like we are in a hurry to apply the new codestyle and don't go deep enough to understand the codestyle config and how the config matches our meets. AFAIK, we agree with the line length limit of 140, but I saw an original value of 100 (fixed in IGNITE-15878. Also, I see we allow missed javadocs for test methods (marked with @Test annotation), but forget to do the same for parameterized tests (@ParameterizedTest and @TestFactory) and even @BeforeEach/BeforeAll/AfterEach/AfterAll. Maybe, the best way is to put here some examples with the code here (e.g. from IDEA setting). The example should be perfectly formatted according to our expectations and cover all the cases. Using the examples the could make a correct PR and another one could easily check PR correctness. > [Ignite 3] Add config for IDEA with codestyle > - > > Key: IGNITE-15377 > URL: https://issues.apache.org/jira/browse/IGNITE-15377 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 3.0.0-alpha2 >Reporter: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > > Let's add editor configuration for IDEA according to a new code style. -- This message was sent by Atlassian Jira (v8.20.1#820001)
