[jira] [Updated] (IGNITE-16334) Calcite. Need to investigate why *Join*Rule ordering can affect the final plan.
[
https://issues.apache.org/jira/browse/IGNITE-16334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-16334:
Labels: calcite calcite2-required ignite-3 (was: calcite calcite2-required
calcite3-required)
> Calcite. Need to investigate why *Join*Rule ordering can affect the final
> plan.
> ---
>
> Key: IGNITE-16334
> URL: https://issues.apache.org/jira/browse/IGNITE-16334
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: calcite, calcite2-required, ignite-3
>
> For now in optimization phase we have such join rules ordering, if
> MergeJoinConverterRule occurs at the end of this enumeration some tests will
> be failed.
> {noformat}
> MergeJoinConverterRule.INSTANCE,
> CorrelatedNestedLoopJoinRule.INSTANCE,
> CorrelateToNestedLoopRule.INSTANCE,
> NestedLoopJoinConverterRule.INSTANCE,
> {noformat}
> Seems [1] can point out the root of such a problem.
> [1] https://issues.apache.org/jira/browse/CALCITE-4542
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21445) IndexQuery ignores pageSize if setLocal=true is set
[
https://issues.apache.org/jira/browse/IGNITE-21445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838473#comment-17838473
]
Ignite TC Bot commented on IGNITE-21445:
{panel:title=Branch: [pull/11317/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/11317/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7830058buildTypeId=IgniteTests24Java8_RunAll]
> IndexQuery ignores pageSize if setLocal=true is set
> ---
>
> Key: IGNITE-21445
> URL: https://issues.apache.org/jira/browse/IGNITE-21445
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.14
>Reporter: Maksim Timonin
>Assignee: Oleg Valuyskiy
>Priority: Major
> Labels: ise
>
> In 2.14, see GridCacheQueryManager#runQuery:L1323
> If query is local it just collects all possible data.
> For ScanQuery this code doesn't work, as it directly uses local
> scanQueryIterator that returns entry one by one.
> Solution:
> # Prepare page for iterating
> # Use the same logic as ScanQuery for local queries.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21404) Do not wrap SqlException into RuntimeException for PlannerHelper.optimize
[
https://issues.apache.org/jira/browse/IGNITE-21404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov reassigned IGNITE-21404:
-
Assignee: Maksim Zhuravkov
> Do not wrap SqlException into RuntimeException for PlannerHelper.optimize
> -
>
> Key: IGNITE-21404
> URL: https://issues.apache.org/jira/browse/IGNITE-21404
> Project: Ignite
> Issue Type: Improvement
> Components: jdbc, sql
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Novikov
>Assignee: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
>
> VolcanoRuleCall.java:250 wrap any exception into RuntimeException, so it can
> break UX for public API as the actual exception will be in cause
>
> {code:java}
> Caused by: java.lang.RuntimeException: Error while applying rule
> ExposeIndexRule, args
> [rel#27:IgniteLogicalTableScan.NONE.[].any(table=[PUBLIC,
> TBL1],filters=AND(=($t2, _UTF-8'v'), =($t3, _UTF-8'v')),requiredColumns={0,
> 1, 2, 3})]
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:250)
> at
> org.apache.calcite.plan.volcano.TopDownRuleDriver.applyGenerator(TopDownRuleDriver.java:151)
> at
> org.apache.calcite.plan.volcano.TopDownRuleDriver.access$600(TopDownRuleDriver.java:51)
> at
> org.apache.calcite.plan.volcano.TopDownRuleDriver$ApplyRule.perform(TopDownRuleDriver.java:532)
> at
> org.apache.calcite.plan.volcano.TopDownRuleDriver.drive(TopDownRuleDriver.java:109)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:524)
> at
> org.apache.calcite.tools.Programs$RuleSetProgram.run(Programs.java:328)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgnitePlanner.transform(IgnitePlanner.java:386)
> at
> org.apache.ignite.internal.sql.engine.prepare.PlannerHelper.optimize(PlannerHelper.java:125)
> at
> org.apache.ignite.internal.sql.engine.planner.AbstractPlannerTest.physicalPlan(AbstractPlannerTest.java:384)
> at
> org.apache.ignite.internal.sql.engine.planner.AbstractPlannerTest.physicalPlan(AbstractPlannerTest.java:372)
> at
> org.apache.ignite.internal.sql.engine.planner.AbstractPlannerTest.physicalPlan(AbstractPlannerTest.java:356)
> at
> org.apache.ignite.internal.sql.engine.planner.AbstractPlannerTest.physicalPlan(AbstractPlannerTest.java:344)
> at
> org.apache.ignite.internal.sql.engine.planner.AbstractPlannerTest.physicalPlan(AbstractPlannerTest.java:333)
> at
> org.apache.ignite.internal.sql.engine.planner.hints.ForceIndexHintPlannerTest.lambda$testWithMultipleIndexHints$0(ForceIndexHintPlannerTest.java:137)
> at
> org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:313)
> {code}
> h3. Steps to reproduce
>
> Replace
> IgniteTestUtils.assertThrowsWithCause to assertThrowsSqlException
> For tests:
> HashIndexPlannerTest#testHashIndexIsNotAppliedWithoutConditions,
> HashIndexPlannerTest#hashIndexIsNotAppliedForRangeCondition
>
> Expected that SqlException will be thrown, not RuntimeException with
> SqlException as cause
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21435) Sql. Catalog DefaultValue should not depend on Serializable.
[
https://issues.apache.org/jira/browse/IGNITE-21435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov reassigned IGNITE-21435:
-
Assignee: Maksim Zhuravkov
> Sql. Catalog DefaultValue should not depend on Serializable.
>
>
> Key: IGNITE-21435
> URL: https://issues.apache.org/jira/browse/IGNITE-21435
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> Currently {{ConstantValue}} (inside
> {{org.apache.ignite.internal.catalog.commands.DefaultValue}}) may hold any
> {{Serializable}} object.
> This should be revised to allow custom serialization.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21822) Sql. Allow to set time zone on per statement basis
[ https://issues.apache.org/jira/browse/IGNITE-21822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin reassigned IGNITE-21822: - Assignee: Pavel Pereslegin > Sql. Allow to set time zone on per statement basis > -- > > Key: IGNITE-21822 > URL: https://issues.apache.org/jira/browse/IGNITE-21822 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Assignee: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > > In IGNITE-21551, support for time zone was added to the sql engine. However, > only Session was updated, while Statement was left intact. Let's eliminate > such a discrepancy by providing an ability to set time zone on per statement > basis. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18647) SQL API: Implement missed Statement and StatementBuilder methods.
[ https://issues.apache.org/jira/browse/IGNITE-18647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin reassigned IGNITE-18647: - Assignee: Pavel Pereslegin > SQL API: Implement missed Statement and StatementBuilder methods. > - > > Key: IGNITE-18647 > URL: https://issues.apache.org/jira/browse/IGNITE-18647 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Assignee: Pavel Pereslegin >Priority: Critical > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21369) Removal of MVCC code in WAL classes
[
https://issues.apache.org/jira/browse/IGNITE-21369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838226#comment-17838226
]
Ilya Shishkov commented on IGNITE-21369:
[~av], thank you a lot for the review!
> Removal of MVCC code in WAL classes
> ---
>
> Key: IGNITE-21369
> URL: https://issues.apache.org/jira/browse/IGNITE-21369
> Project: Ignite
> Issue Type: Sub-task
> Components: mvcc
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Labels: ise
> Fix For: 2.17
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Below classes and corresponding code have to be removed from:
> {{o.a.i.i.pagemem.wal.record}} package:
> * {{LazyMvccDataEntry}}
> * {{MvccDataEntry}}
> * {{MvccDataRecord}}
> * {{MvccTxRecord}}
> * {{UnwrapMvccDataEntry}}
> {{o.a.i.i.pagemem.wal.record.delta}} package:
> * {{DataPageMvccMarkUpdatedRecord}}
> * {{DataPageMvccUpdateNewTxStateHintRecord}}
> * {{DataPageMvccUpdateTxStateHintRecord}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22041) Secondary indexes inline size calculation is wrong
[ https://issues.apache.org/jira/browse/IGNITE-22041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838189#comment-17838189 ] Roman Puchkovskiy commented on IGNITE-22041: The patch looks glorious to me > Secondary indexes inline size calculation is wrong > -- > > Key: IGNITE-22041 > URL: https://issues.apache.org/jira/browse/IGNITE-22041 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > * "short" size is used as 16 bytes instead of 2 bytes > * decimal header is not included in estimation -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22041) Secondary indexes inline size calculation is wrong
[ https://issues.apache.org/jira/browse/IGNITE-22041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-22041: --- Description: * "short" size is used as 16 bytes instead of 2 bytes * decimal header is not included in estimation > Secondary indexes inline size calculation is wrong > -- > > Key: IGNITE-22041 > URL: https://issues.apache.org/jira/browse/IGNITE-22041 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > * "short" size is used as 16 bytes instead of 2 bytes > * decimal header is not included in estimation -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21935) Cover SQL E153(Updatable queries with subqueries) feature by tests
[ https://issues.apache.org/jira/browse/IGNITE-21935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iurii Gerzhedovich reassigned IGNITE-21935: --- Assignee: Iurii Gerzhedovich > Cover SQL E153(Updatable queries with subqueries) feature by tests > -- > > Key: IGNITE-21935 > URL: https://issues.apache.org/jira/browse/IGNITE-21935 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Iurii Gerzhedovich >Priority: Major > Labels: ignite-3 > > We don't have at all any tests for E153(Updatable queries with subqueries) > SQL feature. > Let's cover it and create tickets to fix them in case find any issues related > to the covered area -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21923) Cover SQL E051-09(Basic query specification, Rename columns in the FROM clause) feature by tests
[ https://issues.apache.org/jira/browse/IGNITE-21923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iurii Gerzhedovich reassigned IGNITE-21923: --- Assignee: Iurii Gerzhedovich > Cover SQL E051-09(Basic query specification, Rename columns in the FROM > clause) feature by tests > > > Key: IGNITE-21923 > URL: https://issues.apache.org/jira/browse/IGNITE-21923 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Iurii Gerzhedovich >Priority: Major > Labels: ignite-3 > > We don't have at all any tests for E051-09(Basic query specification, Rename > columns in the FROM clause) SQL feature. > Let's cover it and create tickets to fix them in case find any issues related > to the covered area -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19687) Support default distribution zone reassignment in Catalog
[
https://issues.apache.org/jira/browse/IGNITE-19687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-19687:
--
Fix Version/s: 3.0.0-beta2
> Support default distribution zone reassignment in Catalog
> -
>
> Key: IGNITE-19687
> URL: https://issues.apache.org/jira/browse/IGNITE-19687
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey Mashenkov
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 5h 40m
> Remaining Estimate: 0h
>
> *Motivation.*
> We have no reasonable arguments that we need a special distribution zone
> instance. All distribution zones are equals. Thus, conceptually, any zone can
> be used as default one and can be renamed.
> For better UX, we still can require at least one distribution zone, which is
> currently assigned as default zone, must always exists.
> Let's
> * Avoid using any hardcoded zone id or zone name for getting or detecting the
> default distribution zone.
> * Distributed zone manager shouldn't care which zone is default. Catalog will
> be responsible for resolving default zone if it is not specified when table
> is creating.
> * Add a property in Catalog that will store default zone by zone id.
> * Forbid dropping of distribution zone, which is currently marked as default.
> h3. *Implementation notes*
> We need to enhance {{org.apache.ignite.internal.catalog.Catalog#Catalog}}
> with the default zone id, so when {{UpdateEntry#applyUpdate}} will recreate
> Catalog for a SQL command of setting default zone, the new zone id could be
> saved to Catalog state.
> Also tests must be added here like tests for altering zone and checking that
> tables will use the new default zone, test validation for dropping of
> distribution zone, which is currently marked as default.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22066) Memory leak in the DummyInternalTableImpl
[
https://issues.apache.org/jira/browse/IGNITE-22066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838170#comment-17838170
]
Mikhail Pochatkin commented on IGNITE-22066:
Merged to main 98a2a22830851fca768d864f140e243214949257
> Memory leak in the DummyInternalTableImpl
> -
>
> Key: IGNITE-22066
> URL: https://issues.apache.org/jira/browse/IGNITE-22066
> Project: Ignite
> Issue Type: Bug
>Reporter: Vadim Pakhnushev
>Assignee: Vadim Pakhnushev
>Priority: Major
> Labels: ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Static {{LOW_WATERMARK}} field keeps references to the listeners.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19687) Support default distribution zone reassignment in Catalog
[
https://issues.apache.org/jira/browse/IGNITE-19687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-19687:
--
Ignite Flags: (was: Docs Required,Release Notes Required)
> Support default distribution zone reassignment in Catalog
> -
>
> Key: IGNITE-19687
> URL: https://issues.apache.org/jira/browse/IGNITE-19687
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey Mashenkov
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 5h 40m
> Remaining Estimate: 0h
>
> *Motivation.*
> We have no reasonable arguments that we need a special distribution zone
> instance. All distribution zones are equals. Thus, conceptually, any zone can
> be used as default one and can be renamed.
> For better UX, we still can require at least one distribution zone, which is
> currently assigned as default zone, must always exists.
> Let's
> * Avoid using any hardcoded zone id or zone name for getting or detecting the
> default distribution zone.
> * Distributed zone manager shouldn't care which zone is default. Catalog will
> be responsible for resolving default zone if it is not specified when table
> is creating.
> * Add a property in Catalog that will store default zone by zone id.
> * Forbid dropping of distribution zone, which is currently marked as default.
> h3. *Implementation notes*
> We need to enhance {{org.apache.ignite.internal.catalog.Catalog#Catalog}}
> with the default zone id, so when {{UpdateEntry#applyUpdate}} will recreate
> Catalog for a SQL command of setting default zone, the new zone id could be
> saved to Catalog state.
> Also tests must be added here like tests for altering zone and checking that
> tables will use the new default zone, test validation for dropping of
> distribution zone, which is currently marked as default.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22065) Table partition API
[ https://issues.apache.org/jira/browse/IGNITE-22065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Pochatkin updated IGNITE-22065: --- Description: IEP [IEP-120: MapReduce API - Apache Ignite - Apache Software Foundation|https://cwiki.apache.org/confluence/display/IGNITE/IEP-120%3A+MapReduce+API] Need to implement part about Table API. # Modify Table interface # HashPartition # PartitionManager > Table partition API > --- > > Key: IGNITE-22065 > URL: https://issues.apache.org/jira/browse/IGNITE-22065 > Project: Ignite > Issue Type: Improvement > Components: compute >Reporter: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > > IEP [IEP-120: MapReduce API - Apache Ignite - Apache Software > Foundation|https://cwiki.apache.org/confluence/display/IGNITE/IEP-120%3A+MapReduce+API] > > Need to implement part about Table API. > # Modify Table interface > # HashPartition > # PartitionManager -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22064) General MapReduce API
[ https://issues.apache.org/jira/browse/IGNITE-22064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Pochatkin updated IGNITE-22064: --- Description: IEP [IEP-120: MapReduce API - Apache Ignite - Apache Software Foundation|https://cwiki.apache.org/confluence/display/IGNITE/IEP-120%3A+MapReduce+API] Need to implement part of IEP related to Compute API. # ComputeTask # TaskExecution # Modify IgniteCompute # ComputeJobRunner # TaskContext The part about colocation is not a target for this ticket. > General MapReduce API > - > > Key: IGNITE-22064 > URL: https://issues.apache.org/jira/browse/IGNITE-22064 > Project: Ignite > Issue Type: Improvement > Components: compute >Reporter: Mikhail Pochatkin >Priority: Major > Labels: compute, ignite-3 > > IEP [IEP-120: MapReduce API - Apache Ignite - Apache Software > Foundation|https://cwiki.apache.org/confluence/display/IGNITE/IEP-120%3A+MapReduce+API] > > Need to implement part of IEP related to Compute API. > # ComputeTask > # TaskExecution > # Modify IgniteCompute > # ComputeJobRunner > # TaskContext > The part about colocation is not a target for this ticket. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22056) Sql. Jdbc. Incorrect value can be read for a column with Instant.
[
https://issues.apache.org/jira/browse/IGNITE-22056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22056:
--
Component/s: jdbc
> Sql. Jdbc. Incorrect value can be read for a column with Instant.
> -
>
> Key: IGNITE-22056
> URL: https://issues.apache.org/jira/browse/IGNITE-22056
> Project: Ignite
> Issue Type: Bug
> Components: jdbc, sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> For dates (before 1900 year), we can get the incorrect value using the
> {{ResultSet#getTimestamp}} method (for a column with Instant value (TIMESTAMP
> WITH LOCAL TIME ZONE).
> Reproducer
> {code:java}
> @Test
> public void testTimestamps() throws SQLException {
> // Ignoring time zone.
> TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("UTC")));
> try (Connection conn = DriverManager.getConnection(URL)) {
> try (Statement stmt = conn.createStatement()) {
> stmt.execute(
> "CREATE TABLE t (tt_id INT PRIMARY KEY, dt timestamp, ts
> timestamp with local time zone);"
> + "INSERT INTO t VALUES(0, '1581-12-31 00:00:00',
> '1581-12-31 00:00:00')"
> );
> }
> try (Statement stmt = conn.createStatement()) {
> try (ResultSet rs = stmt.executeQuery("select dt, ts from t")) {
> assertTrue(rs.next());
> Timestamp tsFromDateTime = rs.getTimestamp("dt");
> Timestamp tsFromTimestamp = rs.getTimestamp("ts");
> assertEquals(tsFromDateTime, tsFromTimestamp); // fails
> // Expected :1581-12-31 00:00:00.0
> // Actual :1581-12-21 00:00:00.0
> }
> }
> }
> }
> {code}
> The main problem is a poor implementation of java.sql.Timestamp (and
> java.util.Date).
> To be specific, {{valueOf(LocalDateTime)}} and {{from(Instant)}} may create
> different timestamps for the same dates.
> {code:java}
> TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
> Instant instant = Instant.parse("1581-12-31T00:00:00Z");
> LocalDateTime localDateTime = LocalDateTime.ofInstant(instant,
> ZoneId.of("UTC"));
> Timestamp rightMillisTs = Timestamp.from(instant);
> Timestamp wrongMillisTs = Timestamp.valueOf(localDateTime);
> assertEquals(rightMillisTs.getTime(), wrongMillisTs.getTime()); // fails
> // Expected :-1224417600
> // Actual :-1224331200
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22066) Memory leak in the DummyInternalTableImpl
Vadim Pakhnushev created IGNITE-22066:
-
Summary: Memory leak in the DummyInternalTableImpl
Key: IGNITE-22066
URL: https://issues.apache.org/jira/browse/IGNITE-22066
Project: Ignite
Issue Type: Bug
Reporter: Vadim Pakhnushev
Assignee: Vadim Pakhnushev
Static {{LOW_WATERMARK}} field keeps references to the listeners.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22065) Table partition API
Mikhail Pochatkin created IGNITE-22065: -- Summary: Table partition API Key: IGNITE-22065 URL: https://issues.apache.org/jira/browse/IGNITE-22065 Project: Ignite Issue Type: Improvement Components: compute Reporter: Mikhail Pochatkin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22064) General MapReduce API
Mikhail Pochatkin created IGNITE-22064: -- Summary: General MapReduce API Key: IGNITE-22064 URL: https://issues.apache.org/jira/browse/IGNITE-22064 Project: Ignite Issue Type: Improvement Components: compute Reporter: Mikhail Pochatkin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22062) RO transaction does not close cursor when exception is thrown
[ https://issues.apache.org/jira/browse/IGNITE-22062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov updated IGNITE-22062: --- Description: h3. Motivation If an RO transaction starts and executes some scan operation, and, for some reason, the scan cursor does not close until the transaction is in a final state. The behavior is different for RW transactions because RW transactions go to the final state in case of any exception. Although an RO transaction does not have to be closed in the case of an exception in an operation, a scan cursor that is opened during the operation, is useless and can be closed. h3. Definition of done If an RO transaction gets an exception during a scan operation, the scan cursor has to be closed after the exception is caught by the end user code. was: h3. Motivation If an RO transaction starts and executes some scan operation than by some reason gets an exception, the sacn's cursor does not be close until the transaction is in closed state. The behaior is different for RW transaction, because RW transactions go to final state in case of any exception. Althoug RO transaction does not have to be closed in case of exception in an operation, a scan cursor, that is opened driung the operation, is useless and can be closed. h3. Definition of done If RO transaction gets an exception during scan operation, the scan cursor have to be close after the exception is catched by the end user code. > RO transaction does not close cursor when exception is thrown > - > > Key: IGNITE-22062 > URL: https://issues.apache.org/jira/browse/IGNITE-22062 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > h3. Motivation > If an RO transaction starts and executes some scan operation, and, for some > reason, the scan cursor does not close until the transaction is in a final > state. The behavior is different for RW transactions because RW transactions > go to the final state in case of any exception. > Although an RO transaction does not have to be closed in the case of an > exception in an operation, a scan cursor that is opened during the operation, > is useless and can be closed. > h3. Definition of done > If an RO transaction gets an exception during a scan operation, the scan > cursor has to be closed after the exception is caught by the end user code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22063) aimem partition deletion doesn't delete GC queue
Ivan Bessonov created IGNITE-22063:
--
Summary: aimem partition deletion doesn't delete GC queue
Key: IGNITE-22063
URL: https://issues.apache.org/jira/browse/IGNITE-22063
Project: Ignite
Issue Type: Bug
Reporter: Ivan Bessonov
{{org.apache.ignite.internal.storage.pagememory.mv.VolatilePageMemoryMvPartitionStorage#destroyStructures}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22062) RO transaction does not close cursor when exception is thrown
Vladislav Pyatkov created IGNITE-22062: -- Summary: RO transaction does not close cursor when exception is thrown Key: IGNITE-22062 URL: https://issues.apache.org/jira/browse/IGNITE-22062 Project: Ignite Issue Type: Bug Reporter: Vladislav Pyatkov h3. Motivation If an RO transaction starts and executes some scan operation than by some reason gets an exception, the sacn's cursor does not be close until the transaction is in closed state. The behaior is different for RW transaction, because RW transactions go to final state in case of any exception. Althoug RO transaction does not have to be closed in case of exception in an operation, a scan cursor, that is opened driung the operation, is useless and can be closed. h3. Definition of done If RO transaction gets an exception during scan operation, the scan cursor have to be close after the exception is catched by the end user code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22050) Data structures don't clear partId of reused page
[ https://issues.apache.org/jira/browse/IGNITE-22050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-22050: --- Description: In current implementation we use a single reuse list for all partitions in aimem storage engine. That works fine in Ignite 2, but here in Ignite 3 we implemented a "partitilnless link" format for eliminating 2 bytes, that indicate partition number, from the data in pages. This means that if allocator provided the structure with the page from partition X, but the structure itself represents partition Y, we will lose the "X" in the process and next time will try accessing the page by the pageId that has Y encoded in it. This would lead to pageId mismatch. We have several options here. * ignore mismatched partitions * get rid of partitionless pageIds * fix the allocator, so that it would change partition Id upon allocation Ideally, we should go with the 3rd option. It requires some slight changes in internal data structure API, so that we would pass the required partitionId directly into the allocator (reuse list). This is a little bit excessive at first sight, but seems more appropriate in a long run. Ignite 2 pageIds are all messed up inside of structures, we can fix that. > Data structures don't clear partId of reused page > - > > Key: IGNITE-22050 > URL: https://issues.apache.org/jira/browse/IGNITE-22050 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > In current implementation we use a single reuse list for all partitions in > aimem storage engine. > That works fine in Ignite 2, but here in Ignite 3 we implemented a > "partitilnless link" format for eliminating 2 bytes, that indicate partition > number, from the data in pages. This means that if allocator provided the > structure with the page from partition X, but the structure itself represents > partition Y, we will lose the "X" in the process and next time will try > accessing the page by the pageId that has Y encoded in it. This would lead to > pageId mismatch. > We have several options here. > * ignore mismatched partitions > * get rid of partitionless pageIds > * fix the allocator, so that it would change partition Id upon allocation > Ideally, we should go with the 3rd option. It requires some slight changes in > internal data structure API, so that we would pass the required partitionId > directly into the allocator (reuse list). This is a little bit excessive at > first sight, but seems more appropriate in a long run. Ignite 2 pageIds are > all messed up inside of structures, we can fix that. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21136) SQL: implement functions for date/time formatting
[
https://issues.apache.org/jira/browse/IGNITE-21136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin reassigned IGNITE-21136:
-
Assignee: (was: Pavel Pereslegin)
> SQL: implement functions for date/time formatting
> -
>
> Key: IGNITE-21136
> URL: https://issues.apache.org/jira/browse/IGNITE-21136
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Andrey Khitrin
>Priority: Major
> Labels: ignite-3, sql
>
> SQL functions for date/time formatting are useful in many cases. In AI2, we
> have an universal FORMATDATETIME function for such purposes:
> {code:sql}
> SELECT FORMATDATETIME(CREATION_DATE, '-MM') AS CREATION_MONTH FROM ...
> {code}
> Please imlpement simliar functions in AI3.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-21136) SQL: implement functions for date/time formatting
[
https://issues.apache.org/jira/browse/IGNITE-21136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838071#comment-17838071
]
Pavel Pereslegin edited comment on IGNITE-21136 at 4/17/24 9:51 AM:
We need to investigate if we can support setting FORMAT TEMPLATE using a
dynamic parameter.
If we can’t or it’s extremely complicated, then it is still worth to enable the
{{TO_CHAR}} (and {{TO_TIMESTAMP}}) function.
Example of sql logic test for to_char function
https://gist.github.com/xtern/bc9050cce469565ca4ba5b8c3a623c92
was (Author: xtern):
We need to investigate if we can support setting FORMAT TEMPLATE using a
dynamic parameter.
If we can’t or it’s extremely complicated, then it is still recommended to add
the TO_CHAR (and TO_TIMESTAMP) function.
Example of sql logic test for to_char function
https://gist.github.com/xtern/bc9050cce469565ca4ba5b8c3a623c92
> SQL: implement functions for date/time formatting
> -
>
> Key: IGNITE-21136
> URL: https://issues.apache.org/jira/browse/IGNITE-21136
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Andrey Khitrin
>Priority: Major
> Labels: ignite-3, sql
>
> SQL functions for date/time formatting are useful in many cases. In AI2, we
> have an universal FORMATDATETIME function for such purposes:
> {code:sql}
> SELECT FORMATDATETIME(CREATION_DATE, '-MM') AS CREATION_MONTH FROM ...
> {code}
> Please imlpement simliar functions in AI3.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20799) hibernate-ext: "default-query-results-region" and "default-update-timestamps-region" should not be atomic
[
https://issues.apache.org/jira/browse/IGNITE-20799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov reassigned IGNITE-20799:
--
Assignee: (was: Ilya Shishkov)
> hibernate-ext: "default-query-results-region" and
> "default-update-timestamps-region" should not be atomic
> -
>
> Key: IGNITE-20799
> URL: https://issues.apache.org/jira/browse/IGNITE-20799
> Project: Ignite
> Issue Type: Test
> Components: extensions
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: ise
>
> Currently, Hibernate test job fails because of execution timeout [1]. After
> IGNITE-20579 {{HibernateL2CacheSelfTest}} fails with an error and then hangs:
> {code}
> class org.apache.ignite.IgniteException: Transaction spans operations on
> atomic cache (don't use atomic cache inside a transaction). Since 2.15.0
> atomic operations inside transactions are not allowed by default. Since
> 2.16.0 atomic operations inside transactions are finally forbidden.
> {code}
> As we can see, these problem occur because of ATOMIC caches for Hibernate
> regions "default-query-results-region" and "default-update-timestamps-region"
> [2], but problem can be deeper, because these regions are used under the hood
> by the Hibernate itself *_for query and entity caching_*.
> *Links:*
> #
> https://ci2.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Hibernate?mode=branches#all-projects
> #
> https://github.com/apache/ignite-extensions/blob/master/modules/hibernate-ext/hibernate/src/test/java/org/apache/ignite/cache/hibernate/HibernateL2CacheSelfTest.java#L429
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22061) Use compact representation of BigDecimal with large scale for integers / numbers with trailing zeros
[
https://issues.apache.org/jira/browse/IGNITE-22061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-22061:
Component/s: (was: sql)
> Use compact representation of BigDecimal with large scale for integers /
> numbers with trailing zeros
>
>
> Key: IGNITE-22061
> URL: https://issues.apache.org/jira/browse/IGNITE-22061
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> BigDecimals that represent integer numbers can take up a lot of space, when
> scale is specified:
> {code:java}
> BigDecimal dc = new BigDecimal("").setScale(1024,
> RoundingMode.HALF_UP);
> System.out.println("Difference:");
> System.out.println(MarshallerUtil.sizeInBytes(dc) -
> dc.stripTrailingZeros().setScale(0,
> RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
> {code}
> The code prints:
> {code}
> Difference:
> 427
> {code}
> Let's update BinaryTuple format to store such numbers in more compact form
> that does not store trailing zeros.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22061) Use compact representation of BigDecimal with large scale for integers / numbers with trailing zeros
[
https://issues.apache.org/jira/browse/IGNITE-22061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-22061:
Summary: Use compact representation of BigDecimal with large scale for
integers / numbers with trailing zeros (was: Sql. Use compact representation
of BigDecimal with large scale for integers / numbers with trailing zeros)
> Use compact representation of BigDecimal with large scale for integers /
> numbers with trailing zeros
>
>
> Key: IGNITE-22061
> URL: https://issues.apache.org/jira/browse/IGNITE-22061
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
>
> BigDecimals that represent integer numbers can take up a lot of space, when
> scale is specified:
> {code:java}
> BigDecimal dc = new BigDecimal("").setScale(1024,
> RoundingMode.HALF_UP);
> System.out.println("Difference:");
> System.out.println(MarshallerUtil.sizeInBytes(dc) -
> dc.stripTrailingZeros().setScale(0,
> RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
> {code}
> The code prints:
> {code}
> Difference:
> 427
> {code}
> Let's update BinaryTuple format to store such numbers in more compact form
> that does not store trailing zeros.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-21136) SQL: implement functions for date/time formatting
[
https://issues.apache.org/jira/browse/IGNITE-21136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838071#comment-17838071
]
Pavel Pereslegin edited comment on IGNITE-21136 at 4/17/24 9:59 AM:
We need to investigate if we can support setting FORMAT TEMPLATE using a
dynamic parameter.
If we can’t or it’s extremely complicated, then it is still worth to enable the
{{TO_CHAR}} (and {{TO_TIMESTAMP}}) function.
Example of sql logic test for to_char function
https://gist.github.com/xtern/bc9050cce469565ca4ba5b8c3a623c92
(anyway it worth to wait calcite 1.37, because currently {{TO_CHAR}} produces
invalid results for some cases, see CALCITE-6252)
was (Author: xtern):
We need to investigate if we can support setting FORMAT TEMPLATE using a
dynamic parameter.
If we can’t or it’s extremely complicated, then it is still worth to enable the
{{TO_CHAR}} (and {{TO_TIMESTAMP}}) function.
Example of sql logic test for to_char function
https://gist.github.com/xtern/bc9050cce469565ca4ba5b8c3a623c92
(anyway it worth to wait calcite 1.37, because currently this function works
incorrectly for some cases see CALCITE-6252)
> SQL: implement functions for date/time formatting
> -
>
> Key: IGNITE-21136
> URL: https://issues.apache.org/jira/browse/IGNITE-21136
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Andrey Khitrin
>Priority: Major
> Labels: ignite-3, sql
>
> SQL functions for date/time formatting are useful in many cases. In AI2, we
> have an universal FORMATDATETIME function for such purposes:
> {code:sql}
> SELECT FORMATDATETIME(CREATION_DATE, '-MM') AS CREATION_MONTH FROM ...
> {code}
> Please imlpement simliar functions in AI3.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-21136) SQL: implement functions for date/time formatting
[
https://issues.apache.org/jira/browse/IGNITE-21136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838071#comment-17838071
]
Pavel Pereslegin edited comment on IGNITE-21136 at 4/17/24 9:57 AM:
We need to investigate if we can support setting FORMAT TEMPLATE using a
dynamic parameter.
If we can’t or it’s extremely complicated, then it is still worth to enable the
{{TO_CHAR}} (and {{TO_TIMESTAMP}}) function.
Example of sql logic test for to_char function
https://gist.github.com/xtern/bc9050cce469565ca4ba5b8c3a623c92
(anyway it worth to wait calcite 1.37, because currently this function works
incorrectly for some cases see CALCITE-6252)
was (Author: xtern):
We need to investigate if we can support setting FORMAT TEMPLATE using a
dynamic parameter.
If we can’t or it’s extremely complicated, then it is still worth to enable the
{{TO_CHAR}} (and {{TO_TIMESTAMP}}) function.
Example of sql logic test for to_char function
https://gist.github.com/xtern/bc9050cce469565ca4ba5b8c3a623c92
> SQL: implement functions for date/time formatting
> -
>
> Key: IGNITE-21136
> URL: https://issues.apache.org/jira/browse/IGNITE-21136
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Andrey Khitrin
>Priority: Major
> Labels: ignite-3, sql
>
> SQL functions for date/time formatting are useful in many cases. In AI2, we
> have an universal FORMATDATETIME function for such purposes:
> {code:sql}
> SELECT FORMATDATETIME(CREATION_DATE, '-MM') AS CREATION_MONTH FROM ...
> {code}
> Please imlpement simliar functions in AI3.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21136) SQL: implement functions for date/time formatting
[
https://issues.apache.org/jira/browse/IGNITE-21136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838071#comment-17838071
]
Pavel Pereslegin commented on IGNITE-21136:
---
We need to investigate if we can support setting FORMAT TEMPLATE using a
dynamic parameter.
If we can’t or it’s extremely complicated, then it is still recommended to add
the TO_CHAR (and TO_TIMESTAMP) function.
Example of sql logic test for to_char function
https://gist.github.com/xtern/bc9050cce469565ca4ba5b8c3a623c92
> SQL: implement functions for date/time formatting
> -
>
> Key: IGNITE-21136
> URL: https://issues.apache.org/jira/browse/IGNITE-21136
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Andrey Khitrin
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3, sql
>
> SQL functions for date/time formatting are useful in many cases. In AI2, we
> have an universal FORMATDATETIME function for such purposes:
> {code:sql}
> SELECT FORMATDATETIME(CREATION_DATE, '-MM') AS CREATION_MONTH FROM ...
> {code}
> Please imlpement simliar functions in AI3.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22061) Use compact representation of BigDecimal with large scale for integers / numbers with trailing zeros
[
https://issues.apache.org/jira/browse/IGNITE-22061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22061:
--
Ignite Flags: (was: Docs Required,Release Notes Required)
> Use compact representation of BigDecimal with large scale for integers /
> numbers with trailing zeros
>
>
> Key: IGNITE-22061
> URL: https://issues.apache.org/jira/browse/IGNITE-22061
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> BigDecimals that represent integer numbers can take up a lot of space, when
> scale is specified:
> {code:java}
> BigDecimal dc = new BigDecimal("").setScale(1024,
> RoundingMode.HALF_UP);
> System.out.println("Difference:");
> System.out.println(MarshallerUtil.sizeInBytes(dc) -
> dc.stripTrailingZeros().setScale(0,
> RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
> {code}
> The code prints:
> {code}
> Difference:
> 427
> {code}
> Let's update BinaryTuple format to store such numbers in more compact form
> that does not store trailing zeros.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22061) Use compact representation of BigDecimal with large scale for integers / numbers with trailing zeros
[
https://issues.apache.org/jira/browse/IGNITE-22061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-22061:
Labels: ignite-3 (was: )
> Use compact representation of BigDecimal with large scale for integers /
> numbers with trailing zeros
>
>
> Key: IGNITE-22061
> URL: https://issues.apache.org/jira/browse/IGNITE-22061
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> BigDecimals that represent integer numbers can take up a lot of space, when
> scale is specified:
> {code:java}
> BigDecimal dc = new BigDecimal("").setScale(1024,
> RoundingMode.HALF_UP);
> System.out.println("Difference:");
> System.out.println(MarshallerUtil.sizeInBytes(dc) -
> dc.stripTrailingZeros().setScale(0,
> RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
> {code}
> The code prints:
> {code}
> Difference:
> 427
> {code}
> Let's update BinaryTuple format to store such numbers in more compact form
> that does not store trailing zeros.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22061) Sql. Use compact representation of BigDecimal with large scale for integers / numbers with trailing zeros
[
https://issues.apache.org/jira/browse/IGNITE-22061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22061:
--
Description:
BigDecimals that represent integer numbers can take up a lot of space, when
scale is specified:
{code:java}
BigDecimal dc = new BigDecimal("").setScale(1024,
RoundingMode.HALF_UP);
System.out.println("Difference:");
System.out.println(MarshallerUtil.sizeInBytes(dc) -
dc.stripTrailingZeros().setScale(0,
RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
{code}
The code prints:
{code}
Difference:
427
{code}
Let's update BinaryTuple format to store such numbers in more compact form that
does not store trailing zeros.
was:
BigDecimals that represent integer numbers can take up a lot of space, when
scale is specified:
{code:java}
BigDecimal dc = new BigDecimal("").setScale(1024,
RoundingMode.HALF_UP);
System.out.println("Difference:");
System.out.println(MarshallerUtil.sizeInBytes(dc) -
dc.stripTrailingZeros().setScale(0,
RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
{code}
The code prints:
{code}
Difference:
427
{code}
Let's update BinaryTuple format to store such numbers in more compact form that
ignores trailing zeros.
> Sql. Use compact representation of BigDecimal with large scale for integers /
> numbers with trailing zeros
> -
>
> Key: IGNITE-22061
> URL: https://issues.apache.org/jira/browse/IGNITE-22061
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
>
> BigDecimals that represent integer numbers can take up a lot of space, when
> scale is specified:
> {code:java}
> BigDecimal dc = new BigDecimal("").setScale(1024,
> RoundingMode.HALF_UP);
> System.out.println("Difference:");
> System.out.println(MarshallerUtil.sizeInBytes(dc) -
> dc.stripTrailingZeros().setScale(0,
> RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
> {code}
> The code prints:
> {code}
> Difference:
> 427
> {code}
> Let's update BinaryTuple format to store such numbers in more compact form
> that does not store trailing zeros.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22061) Sql. Use compact representation of BigDecimal with large scale for integers / numbers with trailing zeros
[
https://issues.apache.org/jira/browse/IGNITE-22061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22061:
--
Description:
BigDecimals that represent integer numbers can take up a lot of space, when
scale is specified:
{code:java}
BigDecimal dc = new BigDecimal("").setScale(1024, RoundingMode.HALF_UP);
System.out.println("Difference:");
System.out.println(MarshallerUtil.sizeInBytes(dc) -
dc.stripTrailingZeros().setScale(0,
RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
{code}
The code prints:
{code}
Difference:
427
{code}
Let's update BinaryTuple format to store such numbers in more compact form that
does not store trailing zeros.
was:
BigDecimals that represent integer numbers can take up a lot of space, when
scale is specified:
{code:java}
BigDecimal dc = new BigDecimal("").setScale(1024,
RoundingMode.HALF_UP);
System.out.println("Difference:");
System.out.println(MarshallerUtil.sizeInBytes(dc) -
dc.stripTrailingZeros().setScale(0,
RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
{code}
The code prints:
{code}
Difference:
427
{code}
Let's update BinaryTuple format to store such numbers in more compact form that
does not store trailing zeros.
> Sql. Use compact representation of BigDecimal with large scale for integers /
> numbers with trailing zeros
> -
>
> Key: IGNITE-22061
> URL: https://issues.apache.org/jira/browse/IGNITE-22061
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
>
> BigDecimals that represent integer numbers can take up a lot of space, when
> scale is specified:
> {code:java}
> BigDecimal dc = new BigDecimal("").setScale(1024,
> RoundingMode.HALF_UP);
> System.out.println("Difference:");
> System.out.println(MarshallerUtil.sizeInBytes(dc) -
> dc.stripTrailingZeros().setScale(0,
> RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
> {code}
> The code prints:
> {code}
> Difference:
> 427
> {code}
> Let's update BinaryTuple format to store such numbers in more compact form
> that does not store trailing zeros.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22061) Sql. Use compact representation of BigDecimal with large scale for integers / numbers with trailing zeros
Maksim Zhuravkov created IGNITE-22061:
-
Summary: Sql. Use compact representation of BigDecimal with large
scale for integers / numbers with trailing zeros
Key: IGNITE-22061
URL: https://issues.apache.org/jira/browse/IGNITE-22061
Project: Ignite
Issue Type: Improvement
Components: sql
Reporter: Maksim Zhuravkov
BigDecimals that represent integer numbers can take up a lot of space, when
scale is specified:
{code:java}
BigDecimal dc = new BigDecimal("").setScale(1024,
RoundingMode.HALF_UP);
System.out.println("Difference:");
System.out.println(MarshallerUtil.sizeInBytes(dc) -
dc.stripTrailingZeros().setScale(0,
RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
{code}
The code prints:
{code}
Difference:
427
{code}
Let's update BinaryTuple format to store such numbers in more compact form that
ignores trailing zeros.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20516) Remove openapi.yaml spec from git repository
[ https://issues.apache.org/jira/browse/IGNITE-20516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838059#comment-17838059 ] Mikhail Pochatkin commented on IGNITE-20516: Merged to main c69918e1485eaedc1d2deea648e3f51f08bec15c > Remove openapi.yaml spec from git repository > > > Key: IGNITE-20516 > URL: https://issues.apache.org/jira/browse/IGNITE-20516 > Project: Ignite > Issue Type: Task > Components: rest >Affects Versions: 3.0.0-beta1 >Reporter: Dmitry Baranov >Assignee: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > Time Spent: 20m > Remaining Estimate: 0h > > Source of truth for rest api should be java code. So, generated openapi spec > should not be saved in repo (modules/rest-api/openapi/openapi.yaml) > spec should be provided as artifact in TC -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-13919) Calcite integration. Single group aggregates
[
https://issues.apache.org/jira/browse/IGNITE-13919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-13919:
Labels: calcite (was: calcite calcite3-required)
> Calcite integration. Single group aggregates
>
>
> Key: IGNITE-13919
> URL: https://issues.apache.org/jira/browse/IGNITE-13919
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Taras Ledkov
>Assignee: Aleksey Plekhanov
>Priority: Minor
> Labels: calcite
> Fix For: 2.15
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> Investigate the optimization for single group aggregates,
> e.g.: {{SELECT FROM }}
> Now the hash based aggregates are used for this case.
> We can obtain a little performance improvement.
> Also the special cases (e.g.: {{SELECT COUNT() FROM }})
> may be optimized to use table/cache size.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17984) Calcite engine. Memory quotas
[ https://issues.apache.org/jira/browse/IGNITE-17984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iurii Gerzhedovich updated IGNITE-17984: Labels: calcite iep-96 important (was: calcite calcite3-required iep-96 important) > Calcite engine. Memory quotas > - > > Key: IGNITE-17984 > URL: https://issues.apache.org/jira/browse/IGNITE-17984 > Project: Ignite > Issue Type: New Feature >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: calcite, iep-96, important > Fix For: 2.15 > > Time Spent: 0.5h > Remaining Estimate: 0h > > It's required to have an ability to set heap memory usage quotas for query > execution engine (global and for each query). > See > [IEP-96|https://cwiki.apache.org/confluence/display/IGNITE/IEP-96+Calcite+SQL+engine+memory+quotas] > for details. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22056) Sql. Jdbc. Incorrect value can be read for a column with Instant.
[
https://issues.apache.org/jira/browse/IGNITE-22056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22056:
--
Description:
For dates (before 1900 year), we can get the incorrect value using the
{{ResultSet#getTimestamp}} method (for a column with Instant value (TIMESTAMP
WITH LOCAL TIME ZONE).
Reproducer
{code:java}
@Test
public void testTimestamps() throws SQLException {
// Ignoring time zone.
TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("UTC")));
try (Connection conn = DriverManager.getConnection(URL)) {
try (Statement stmt = conn.createStatement()) {
stmt.execute(
"CREATE TABLE t (tt_id INT PRIMARY KEY, dt timestamp, ts
timestamp with local time zone);"
+ "INSERT INTO t VALUES(0, '1581-12-31 00:00:00',
'1581-12-31 00:00:00')"
);
}
try (Statement stmt = conn.createStatement()) {
try (ResultSet rs = stmt.executeQuery("select dt, ts from t")) {
assertTrue(rs.next());
Timestamp tsFromDateTime = rs.getTimestamp("dt");
Timestamp tsFromTimestamp = rs.getTimestamp("ts");
assertEquals(tsFromDateTime, tsFromTimestamp); // fails
// Expected :1581-12-31 00:00:00.0
// Actual :1581-12-21 00:00:00.0
}
}
}
}
{code}
The main problem is a poor implementation of java.sql.Timestamp (and
java.util.Date).
To be specific, {{valueOf(LocalDateTime)}} and {{from(Instant)}} may create
different timestamps for the same dates.
{code:java}
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
Instant instant = Instant.parse("1581-12-31T00:00:00Z");
LocalDateTime localDateTime = LocalDateTime.ofInstant(instant,
ZoneId.of("UTC"));
Timestamp rightMillisTs = Timestamp.from(instant);
Timestamp wrongMillisTs = Timestamp.valueOf(localDateTime);
assertEquals(rightMillisTs.getTime(), wrongMillisTs.getTime()); // fails
// Expected :-1224417600
// Actual :-1224331200
{code}
was:
For dates (before 1900 year), we can get the incorrect value using the
{{ResultSet#getTimestamp}} method (for a column with Instant value (TIMESTAMP
WITH TIME ZONE).
Reproducer
{code:java}
@Test
public void testTimestamps() throws SQLException {
// Ignoring time zone.
TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("UTC")));
try (Connection conn = DriverManager.getConnection(URL)) {
try (Statement stmt = conn.createStatement()) {
stmt.execute(
"CREATE TABLE t (tt_id INT PRIMARY KEY, dt timestamp, ts
timestamp with local time zone);"
+ "INSERT INTO t VALUES(0, '1581-12-31 00:00:00',
'1581-12-31 00:00:00')"
);
}
try (Statement stmt = conn.createStatement()) {
try (ResultSet rs = stmt.executeQuery("select dt, ts from t")) {
assertTrue(rs.next());
Timestamp tsFromDateTime = rs.getTimestamp("dt");
Timestamp tsFromTimestamp = rs.getTimestamp("ts");
assertEquals(tsFromDateTime, tsFromTimestamp); // fails
// Expected :1581-12-31 00:00:00.0
// Actual :1581-12-21 00:00:00.0
}
}
}
}
{code}
The main problem is a poor implementation of java.sql.Timestamp (and
java.util.Date).
To be specific, {{valueOf(LocalDateTime)}} and {{from(Instant)}} may create
different timestamps for the same dates.
{code:java}
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
Instant instant = Instant.parse("1581-12-31T00:00:00Z");
LocalDateTime localDateTime = LocalDateTime.ofInstant(instant,
ZoneId.of("UTC"));
Timestamp rightMillisTs = Timestamp.from(instant);
Timestamp wrongMillisTs = Timestamp.valueOf(localDateTime);
assertEquals(rightMillisTs.getTime(), wrongMillisTs.getTime()); // fails
// Expected :-1224417600
// Actual :-1224331200
{code}
> Sql. Jdbc. Incorrect value can be read for a column with Instant.
> -
>
> Key: IGNITE-22056
> URL: https://issues.apache.org/jira/browse/IGNITE-22056
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> For dates (before 1900 year), we can get the incorrect value using the
> {{ResultSet#getTimestamp}} method (for a column with Instant value (TIMESTAMP
> WITH LOCAL TIME ZONE).
> Reproducer
> {code:java}
> @Test
> public void testTimestamps() throws SQLException {
> // Ignoring time zone.
> TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("UTC")));
> try (Connection conn = DriverManager.getConnection(URL)) {
>
[jira] [Resolved] (IGNITE-19962) Actualize list of 3rd party dependencies for AI 3.0
[ https://issues.apache.org/jira/browse/IGNITE-19962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vadim Kolodin resolved IGNITE-19962. Resolution: Resolved devlist thread [AI3 3rd party dependencies-Apache Mail Archives|https://lists.apache.org/thread/3d18s2cjyyqktp0573n8qkjk4265dr5q] > Actualize list of 3rd party dependencies for AI 3.0 > --- > > Key: IGNITE-19962 > URL: https://issues.apache.org/jira/browse/IGNITE-19962 > Project: Ignite > Issue Type: Improvement >Reporter: Iurii Gerzhedovich >Assignee: Vadim Kolodin >Priority: Blocker > Labels: ignite-3 > > AI3 codestyle guide contains part about using 3rd party libraries. Right now > the document present just 5 such libraries, however we already use > signifignetely more. > Let's do two steps: > # analizy which dependencies could be get rid, even in tests. We must have > minimum dependency for whole project. > # Actualize list of 3rd party libraries in > [codestyle|https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-2Using3rdpartylibraries]]. > The first step should be discussed at developers mailing list and have strong > explanation of necessety for each of dependencies. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21369) Removal of MVCC code in WAL classes
[
https://issues.apache.org/jira/browse/IGNITE-21369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838034#comment-17838034
]
Ignite TC Bot commented on IGNITE-21369:
{panel:title=Branch: [pull/11204/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/11204/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7828054buildTypeId=IgniteTests24Java8_RunAll]
> Removal of MVCC code in WAL classes
> ---
>
> Key: IGNITE-21369
> URL: https://issues.apache.org/jira/browse/IGNITE-21369
> Project: Ignite
> Issue Type: Sub-task
> Components: mvcc
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Labels: ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Below classes and corresponding code have to be removed from:
> {{o.a.i.i.pagemem.wal.record}} package:
> * {{LazyMvccDataEntry}}
> * {{MvccDataEntry}}
> * {{MvccDataRecord}}
> * {{MvccTxRecord}}
> * {{UnwrapMvccDataEntry}}
> {{o.a.i.i.pagemem.wal.record.delta}} package:
> * {{DataPageMvccMarkUpdatedRecord}}
> * {{DataPageMvccUpdateNewTxStateHintRecord}}
> * {{DataPageMvccUpdateTxStateHintRecord}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22056) Sql. Jdbc. Incorrect value can be read for a column with Instant.
[
https://issues.apache.org/jira/browse/IGNITE-22056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22056:
--
Description:
For dates (before 1900 year), we can get the incorrect value using the
{{ResultSet#getTimestamp}} method (for a column with Instant value (TIMESTAMP
WITH TIME ZONE).
Reproducer
{code:java}
@Test
public void testTimestamps() throws SQLException {
// Ignoring time zone.
TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("UTC")));
try (Connection conn = DriverManager.getConnection(URL)) {
try (Statement stmt = conn.createStatement()) {
stmt.execute(
"CREATE TABLE t (tt_id INT PRIMARY KEY, dt timestamp, ts
timestamp with local time zone);"
+ "INSERT INTO t VALUES(0, '1581-12-31 00:00:00',
'1581-12-31 00:00:00')"
);
}
try (Statement stmt = conn.createStatement()) {
try (ResultSet rs = stmt.executeQuery("select dt, ts from t")) {
assertTrue(rs.next());
Timestamp tsFromDateTime = rs.getTimestamp("dt");
Timestamp tsFromTimestamp = rs.getTimestamp("ts");
assertEquals(tsFromDateTime, tsFromTimestamp); // fails
// Expected :1581-12-31 00:00:00.0
// Actual :1581-12-21 00:00:00.0
}
}
}
}
{code}
The main problem is a poor implementation of java.sql.Timestamp (and
java.util.Date).
To be specific, {{valueOf(LocalDateTime)}} and {{from(Instant)}} may create
different timestamps for the same dates.
{code:java}
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
Instant instant = Instant.parse("1581-12-31T00:00:00Z");
LocalDateTime localDateTime = LocalDateTime.ofInstant(instant,
ZoneId.of("UTC"));
Timestamp rightMillisTs = Timestamp.from(instant);
Timestamp wrongMillisTs = Timestamp.valueOf(localDateTime);
assertEquals(rightMillisTs.getTime(), wrongMillisTs.getTime()); // fails
// Expected :-1224417600
// Actual :-1224331200
{code}
was:
For dates (before 1900 year), we can get the incorrect value using the
{{ResultSet#getTimestamp}} method (for a column with Instant value (TIMESTAMP
WITH TIME ZONE).
Reproducer
{code:java}
@Test
public void testTimestamps() throws SQLException {
// Ignoring time zone.
TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("UTC")));
try (Connection conn = DriverManager.getConnection(URL)) {
try (Statement stmt = conn.createStatement()) {
stmt.execute(
"CREATE TABLE t (tt_id INT PRIMARY KEY, dt timestamp, ts
timestamp with local time zone);"
+ "INSERT INTO t VALUES(0, '1581-12-31 00:00:00',
'1581-12-31 00:00:00')"
);
}
try (Statement stmt = conn.createStatement()) {
try (ResultSet rs = stmt.executeQuery("select dt, ts from t")) {
assertTrue(rs.next());
Timestamp tsFromDateTime = rs.getTimestamp("dt");
Timestamp tsFromTimestamp = rs.getTimestamp("ts");
assertEquals(tsFromDateTime, tsFromTimestamp); // fails
// Expected :1581-12-31 00:00:00.0
// Actual :1581-12-21 00:00:00.0
}
}
}
}
{code}
The main problem is a poor implementation of java.sql.Timestamp.
To be specific, {{valueOf(LocalDateTime)}} and {{from(Instant)}} constructs
different timestamps, even for the same dates.
{code:java}
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
Instant instant = Instant.parse("1581-12-31T00:00:00Z");
LocalDateTime localDateTime = LocalDateTime.ofInstant(instant,
ZoneId.of("UTC"));
Timestamp rightMillisTs = Timestamp.from(instant);
Timestamp wrongMillisTs = Timestamp.valueOf(localDateTime);
assertEquals(rightMillisTs.getTime(), wrongMillisTs.getTime()); // fails
// Expected :-1224417600
// Actual :-1224331200
{code}
> Sql. Jdbc. Incorrect value can be read for a column with Instant.
> -
>
> Key: IGNITE-22056
> URL: https://issues.apache.org/jira/browse/IGNITE-22056
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> For dates (before 1900 year), we can get the incorrect value using the
> {{ResultSet#getTimestamp}} method (for a column with Instant value (TIMESTAMP
> WITH TIME ZONE).
> Reproducer
> {code:java}
> @Test
> public void testTimestamps() throws SQLException {
> // Ignoring time zone.
> TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("UTC")));
> try (Connection conn = DriverManager.getConnection(URL)) {
> try (Statement stmt =
[jira] [Updated] (IGNITE-22055) Shut destruction executor down before closing volatile regions
[ https://issues.apache.org/jira/browse/IGNITE-22055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-22055: --- Description: Closure order is reversed, we need to fix it. > Shut destruction executor down before closing volatile regions > -- > > Key: IGNITE-22055 > URL: https://issues.apache.org/jira/browse/IGNITE-22055 > Project: Ignite > Issue Type: Bug >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > Closure order is reversed, we need to fix it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22060) Sql. Enable sql logic tests for NOT NULL constraint violation
[ https://issues.apache.org/jira/browse/IGNITE-22060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-22060: -- Summary: Sql. Enable sql logic tests for NOT NULL constraint violation (was: Sql. Enable sql logic tests for NOT NULL constraint violation.) > Sql. Enable sql logic tests for NOT NULL constraint violation > - > > Key: IGNITE-22060 > URL: https://issues.apache.org/jira/browse/IGNITE-22060 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Assignee: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > > Many tests in not_null_constraint_violation are skipped but they should be > enabled. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22060) Sql. Enable sql logic tests for NOT NULL constraint violation.
[ https://issues.apache.org/jira/browse/IGNITE-22060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-22060: -- Summary: Sql. Enable sql logic tests for NOT NULL constraint violation. (was: Sql. Enable sql logic test for NOT NULL constraint violation.) > Sql. Enable sql logic tests for NOT NULL constraint violation. > -- > > Key: IGNITE-22060 > URL: https://issues.apache.org/jira/browse/IGNITE-22060 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Assignee: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > > Many tests in not_null_constraint_violation are skipped but they should be > enabled. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22060) Sql. Enable sql logic test for NOT NULL constraint violation.
Maksim Zhuravkov created IGNITE-22060: - Summary: Sql. Enable sql logic test for NOT NULL constraint violation. Key: IGNITE-22060 URL: https://issues.apache.org/jira/browse/IGNITE-22060 Project: Ignite Issue Type: Improvement Components: sql Reporter: Maksim Zhuravkov Many tests in not_null_constraint_violation are skipped but they should be enabled. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22060) Sql. Enable sql logic test for NOT NULL constraint violation.
[ https://issues.apache.org/jira/browse/IGNITE-22060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov reassigned IGNITE-22060: - Assignee: Maksim Zhuravkov > Sql. Enable sql logic test for NOT NULL constraint violation. > - > > Key: IGNITE-22060 > URL: https://issues.apache.org/jira/browse/IGNITE-22060 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Assignee: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > > Many tests in not_null_constraint_violation are skipped but they should be > enabled. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-22055) Shut destruction executor down before closing volatile regions
[ https://issues.apache.org/jira/browse/IGNITE-22055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov resolved IGNITE-22055. Reviewer: Ivan Bessonov Resolution: Fixed > Shut destruction executor down before closing volatile regions > -- > > Key: IGNITE-22055 > URL: https://issues.apache.org/jira/browse/IGNITE-22055 > Project: Ignite > Issue Type: Bug >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22060) Sql. Enable sql logic test for NOT NULL constraint violation.
[ https://issues.apache.org/jira/browse/IGNITE-22060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-22060: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Sql. Enable sql logic test for NOT NULL constraint violation. > - > > Key: IGNITE-22060 > URL: https://issues.apache.org/jira/browse/IGNITE-22060 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Assignee: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > > Many tests in not_null_constraint_violation are skipped but they should be > enabled. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21771) Deal with the case of catalog compaction
[ https://issues.apache.org/jira/browse/IGNITE-21771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-21771: --- Epic Link: IGNITE-22059 (was: IGNITE-21450) > Deal with the case of catalog compaction > > > Key: IGNITE-21771 > URL: https://issues.apache.org/jira/browse/IGNITE-21771 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > > See TODOs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21547) Understand the fields of CatalogIndexDescriptor
[ https://issues.apache.org/jira/browse/IGNITE-21547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-21547: --- Epic Link: IGNITE-22059 (was: IGNITE-21450) > Understand the fields of CatalogIndexDescriptor > --- > > Key: IGNITE-21547 > URL: https://issues.apache.org/jira/browse/IGNITE-21547 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > > In tickets previously, various specific fields were added to > *org.apache.ignite.internal.catalog.descriptors.CatalogIndexDescriptor* that > do not need to be stored in a descriptor and can be stored in auxiliary > entities, for example in vault. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22059) Catalog compaction support in indexes
Roman Puchkovskiy created IGNITE-22059: -- Summary: Catalog compaction support in indexes Key: IGNITE-22059 URL: https://issues.apache.org/jira/browse/IGNITE-22059 Project: Ignite Issue Type: Epic Reporter: Roman Puchkovskiy When making initial integration of dynamic indeces with the system in IGNITE-20782, an assumption was assumed (for simplicity) that the Catalog never gets compacted. To make it possible to enable the compaction of the Catalog in IGNITE-21991, we need to prepare code related to indexes to the Catalog compaction. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22057) destruction_does_not_update_data is flaky
[
https://issues.apache.org/jira/browse/IGNITE-22057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-22057:
-
Description:
Seems that `destruction_does_not_update_data` may hang forever on tx rollback
which causes
{code:java}
The build [Test]::> Run :: C++ Linux Tests #24053 {buildId=8040877} has been
running for more than 15 minutes. Terminating...{code}
{code:java}
[08:15:21] : [Step 8/12] [ RUN ]
transactions_test.rollback_does_not_update_data
[08:15:21] : [Step 8/12] [ ] [ INFO ] Established connection
with remote host 127.0.0.1:10942
[08:15:21] : [Step 8/12] [ ] [ DEBUG ] Connection ID: 1
[08:15:21] : [Step 8/12] [ ] [ DEBUG ] Handshake sent
successfully
[08:15:21] : [Step 8/12] [ ] [ DEBUG ] Message sent successfully
on Connection ID 1
[08:15:21] : [Step 8/12] [ ] [ DEBUG ] Message sent successfully
on Connection ID 1
[08:15:21] : [Step 8/12] [ ] [ DEBUG ] Message on Connection ID
1, size: 149
[08:15:21] : [Step 8/12] [ ] [ DEBUG ] Got handshake response
[08:15:21] : [Step 8/12] [ ] [ DEBUG ] Server-side protocol
version: 3.0.0
[08:15:21] : [Step 8/12] [ ] [ DEBUG ] Performing request:
op=50, req_id=0
[08:15:21] : [Step 8/12] [ ] [ DEBUG ] Message sent successfully
on Connection ID 1
[08:15:21] : [Step 8/12] [ ] [ DEBUG ] Message sent successfully
on Connection ID 1
[08:15:21] : [Step 8/12] [ ] [ DEBUG ] Message on Connection ID
1, size: 26
[08:15:21] : [Step 8/12] [ ] [ DEBUG ] Closed Connection ID 1,
error=Client stopped
[08:15:21] : [Step 8/12] [ ] [ INFO ] Established connection
with remote host 127.0.0.1:10942
[08:15:21] : [Step 8/12] [ ] [ DEBUG ] Connection ID: 1
[08:15:21] : [Step 8/12] [ ] [ DEBUG ] Handshake sent
successfully
[08:15:21] : [Step 8/12] [ ] [ DEBUG ] Message sent successfully
on Connection ID 1
[08:15:21] : [Step 8/12] [ ] [ DEBUG ] Message sent successfully
on Connection ID 1
[08:15:21] : [Step 8/12] [ ] [ DEBUG ] Message on Connection ID
1, size: 149
[08:15:21] : [Step 8/12] [ ] [ DEBUG ] Got handshake response
[08:15:21] : [Step 8/12] [ ] [ DEBUG ] Server-side protocol
version: 3.0.0
[08:15:21] : [Step 8/12] [ ] [ DEBUG ] Performing request: op=4,
req_id=0
[08:15:21] : [Step 8/12] [ ] [ DEBUG ] Message sent successfully
on Connection ID 1
[08:15:21] : [Step 8/12] [ ] [ DEBUG ] Message sent successfully
on Connection ID 1
[08:15:21] : [Step 8/12] [ ] [ DEBUG ] Message on Connection ID
1, size: 21
[08:15:21] : [Step 8/12] [ ] [ DEBUG ] Performing request:
op=43, req_id=1
[08:15:21] : [Step 8/12] [ ] [ DEBUG ] Message sent successfully
on Connection ID 1
[08:15:21] : [Step 8/12] [ ] [ DEBUG ] Message sent successfully
on Connection ID 1
[08:15:21] : [Step 8/12] [ ] [ DEBUG ] Message on Connection ID
1, size: 12
[08:15:21] : [Step 8/12] [ ] [ DEBUG ] Performing request: op=5,
req_id=2
[08:15:21] : [Step 8/12] [ ] [ DEBUG ] Message sent successfully
on Connection ID 1
[08:15:21] : [Step 8/12] [ ] [ DEBUG ] Message sent successfully
on Connection ID 1
[08:15:21] : [Step 8/12] [ ] [ DEBUG ] Message on Connection ID
1, size: 36
[08:15:21] : [Step 8/12] [ ] [ DEBUG ] Performing request:
op=10, req_id=3
[08:15:21] : [Step 8/12] [ ] [ DEBUG ] Message sent successfully
on Connection ID 1
[08:15:21] : [Step 8/12] [ ] [ DEBUG ] Message sent successfully
on Connection ID 1
[08:15:21] : [Step 8/12] [ ] [ DEBUG ] Message on Connection ID
1, size: 12
[08:15:21] : [Step 8/12] [ ] [ DEBUG ] Performing request:
op=45, req_id=4
[08:15:21] : [Step 8/12] [ ] [ DEBUG ] Message sent successfully
on Connection ID 1
[08:15:21] : [Step 8/12] [ ] [ DEBUG ] Message sent successfully
on Connection ID 1
[08:15:21] : [Step 8/12] [ ] [ DEBUG ] Message on Connection ID
1, size: 11
[08:15:21] : [Step 8/12] [ ] [ DEBUG ] Performing request:
op=12, req_id=5
[08:15:21] : [Step 8/12] [ ] [ DEBUG ] Message sent successfully
on Connection ID 1
[08:15:21] : [Step 8/12] [ ] [ DEBUG ] Message sent successfully
on Connection ID 1
[08:15:21] : [Step 8/12] [ ] [ DEBUG ] Message on Connection ID
1, size: 13
[08:15:21] : [Step 8/12] [ ] [ INFO ] Established connection
with remote host 127.0.0.1:10942
[08:15:21] : [Step 8/12] [ ] [ DEBUG ] Connection ID: 1
[08:15:21] :
[jira] [Commented] (IGNITE-21799) A transaction rollback fails with assertion error
[
https://issues.apache.org/jira/browse/IGNITE-21799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837998#comment-17837998
]
Roman Puchkovskiy commented on IGNITE-21799:
[~amashenkov] could you please verify if it works on the current main? There
was a fix related to this in IGNITE-21924, it seems to work for me now.
> A transaction rollback fails with assertion error
> -
>
> Key: IGNITE-21799
> URL: https://issues.apache.org/jira/browse/IGNITE-21799
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> A transaction rollback fails with
> {noformat}
> java.lang.AssertionError: Thread does not have allowed operations
> {noformat}
> Here is a simple reproducer below.
> You can use an`ItCommonsApiTest` to reproduce.
> {code:java}
> @Test
> public void rollbackAsync() {
> Ignite node = CLUSTER.aliveNode();
> sql("CREATE TABLE IF NOT EXISTS TEST(ID INT PRIMARY KEY, VAL0 INT)");
> KeyValueView view1 =
> node.tables().table("TEST").keyValueView();
> AtomicReference> rollbackFut = new
> AtomicReference<>();
>
> Transaction tx = node.transactions().begin();
> view1.getAsync(tx, Tuple.create().set("id", 101))
> .handle((unused, err) -> {
> rollbackFut.set(tx.rollbackAsync()); // unconditional
> roll back
> return null;
> }).join();
> rollbackFut.get().join(); // <- FAILS
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22057) destruction_does_not_update_data is flaky
[ https://issues.apache.org/jira/browse/IGNITE-22057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-22057: - Description: Seems that > destruction_does_not_update_data is flaky > - > > Key: IGNITE-22057 > URL: https://issues.apache.org/jira/browse/IGNITE-22057 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > > Seems that -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22058) Use paranoid leak detection in tests
Ivan Bessonov created IGNITE-22058: -- Summary: Use paranoid leak detection in tests Key: IGNITE-22058 URL: https://issues.apache.org/jira/browse/IGNITE-22058 Project: Ignite Issue Type: Improvement Reporter: Ivan Bessonov Fix For: 3.0.0-beta2 We should set `io.netty.leakDetection.level=paranoid` in integration tests and network tests, in order to detect possible leaks -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22057) destruction_does_not_update_data is flaky
[ https://issues.apache.org/jira/browse/IGNITE-22057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-22057: - Labels: ignite-3 (was: ) > destruction_does_not_update_data is flaky > - > > Key: IGNITE-22057 > URL: https://issues.apache.org/jira/browse/IGNITE-22057 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22057) destruction_does_not_update_data is flaky
Alexander Lapin created IGNITE-22057: Summary: destruction_does_not_update_data is flaky Key: IGNITE-22057 URL: https://issues.apache.org/jira/browse/IGNITE-22057 Project: Ignite Issue Type: Bug Reporter: Alexander Lapin -- This message was sent by Atlassian Jira (v8.20.10#820010)
