[jira] [Updated] (IGNITE-18304) [IEP-94] Remove daemon node
[ https://issues.apache.org/jira/browse/IGNITE-18304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-18304: --- Labels: IEP-80 IEP-94 important (was: IEP-80 IEP-94) > [IEP-94] Remove daemon node > --- > > Key: IGNITE-18304 > URL: https://issues.apache.org/jira/browse/IGNITE-18304 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-80, IEP-94, important > Fix For: 2.15 > > Time Spent: 20m > Remaining Estimate: 0h > > We can remove daemon node and related code because they no longer used -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-8801) Change default behaviour of atomic operations inside transactions
[
https://issues.apache.org/jira/browse/IGNITE-8801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-8801:
--
Flags: (was: Important)
> Change default behaviour of atomic operations inside transactions
> -
>
> Key: IGNITE-8801
> URL: https://issues.apache.org/jira/browse/IGNITE-8801
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Ryabov Dmitrii
>Assignee: Julia Bakulina
>Priority: Minor
> Labels: ise
> Fix For: 2.15
>
> Time Spent: 5h
> Remaining Estimate: 0h
>
> Need to change default behaviour of atomic operations to fail inside
> transactions.
> 1) Remove IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property.
> 2) Set default value to restrict atomic operations in
> {{CacheOperationContext}} constructor without arguments and arguments for
> calls of another constructor.
> 3) Fix javadocs.
> As per the latest round of discussion on Ignite Dev List as of 28/10/2022 we
> agreed on the following:
> 1) Revert deprecation IGNITE-17916 - reverted
> 2) Change default value in 2.15.
> 3) Notify users in release notes, an exception message - how to change the
> behavior back.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18301) [IEP-94] Remove ignitevisorcmd and related modules
[ https://issues.apache.org/jira/browse/IGNITE-18301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-18301: --- Labels: IEP-94 important (was: IEP-94) > [IEP-94] Remove ignitevisorcmd and related modules > -- > > Key: IGNITE-18301 > URL: https://issues.apache.org/jira/browse/IGNITE-18301 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Minor > Labels: IEP-94, important > Fix For: 2.15 > > Time Spent: 20m > Remaining Estimate: 0h > > Remove ignitevisorcmd and related modules -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-15322) System tasks should run without any explicitly granted permissions
[
https://issues.apache.org/jira/browse/IGNITE-15322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-15322:
---
Labels: important ise (was: ise)
> System tasks should run without any explicitly granted permissions
> --
>
> Key: IGNITE-15322
> URL: https://issues.apache.org/jira/browse/IGNITE-15322
> Project: Ignite
> Issue Type: Bug
> Components: compute, security
>Reporter: Ilya Kazakov
>Assignee: Mikhail Petrov
>Priority: Minor
> Labels: important, ise
> Fix For: 2.15
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> For example, this code needs TASK_EXECUTE permissions.
> {code:java}
> Affinity affinity = ignite.affinity("TEST");
> affinity.mapKeysToNodes(Arrays.asList(1L,100L, 1000L));{code}
> This is unexpected behavior, because:
> - the task started implicitly (under the hood), customer should not to know
> about it.
> - this is a system task (not defined by a customer), the tasks needs for a
> normal grid workflow.
> Also, I suppose there are any other implicitly tasks, which could lead to
> unexpected behavior (need permissions).
> Proposed way to solve this issue:
> 1. Add mechanism to destinguish whether task class is SYSTEM (part of the
> Ignite codebase) or USER.
> Here we can reuse SecurityUtils#isSystemType mechanism that is used in Ignite
> Sanbox implementation.
> 2. Add mechanism to detect if task execution was initiated by the user
> (PUBLIC CALL) or by the Ignite system itself (INTERNAL CALL).
> It seems that the easiest way to achieve this is to completely separate the
> public and private Compute APIs.
> Task executioin requests received through Ignite Thin Clients are considered
> PUBLIC CALLs.
> The first two steps give us the ability to
> A. safely skip authorization of SYSTEM tasks which are
> called through INTERNAL API.
> B. keep authorization of PUBLIC tasks intact
> C. prevent users of calling SYSTEM tasks directly through PUBLIC API ( it
> means that all user task execution requests received through REST or Thin
> client protocols MUST be executed through PUBLIC API).
> 3. Add the ability to explicitly specify for SYSTEM
> task/callable/runnable/closure what permission should be checked before its
> execution.
> It can be solved by introducing optional interface that compute job can
> implement.
> {code:java}
> /** */
> public interface PublicAccessJob {
> /** */
> public SecurityPermissionSet requiredPermissions();
> }
> {code}
> 4. SYSTEM tasks can splitted into two categories -
> SYSTEM INTERNAL (tasks that are not available to the user) and SYSTEM PUBLIC
> tasks (tasks that are part oof the ignite code but are available to the user
> and can be executed through the PUBLIC API)
> Example of SYSTEM public tasks - Visor tasks on which the user control script
> is implemented
> They are executed through Thin Client which is considered Public API.
> Considering that SYSTEM PUBLIC tasks can potentially be executed by the user,
> we must force the developer to explicitly specify permissions for tasks of
> this type. It can be done by checking that SYSTEM tasks that are executed
> through PUBLIC API impelements PublicAwareJob interface described above.
> ||X||Public API||Private API||
> |PUBLIC task|auth by task name|restricted|
> |SYSTEM INTERNAL task|restricted|auth skipped|
> |SYSTEM PUBLIC task|auth by explicitly specified permissions|auth skipped|
> By the way the PublicAccessJob interface, implemented by all Visor jobs,
> allows you to specify for each specific Visor job what permissions it
> requires. Also it is proposed to guard all Visor Jobs with ADMIN_OPS
> permission by default.
> 5. Authorization of SYSTEM tasks cancellation must be skipped it they are
> canceled by the same user who started them, oterwise dedicated permissions is
> required (e.g. ADMIN_KILL). USER tasks cancellation is performed by their
> names.
> Possible troubles:
> 1. Mentioned SecurityUtils#isSystemType works only for the ignite-core
> module. If some tasks are defined inside other Ignite modules - they will not
> be considered SYSTEM. Currently there are no such task.
> 2. Currently all DotNet code is wrapped and executed via special SYSTEM
> tasks. As a result all DotNet runnable/callable/tasks are authorized by the
> name of the SYSTEM wrapper task. So if TASK_EXECUTE permissions for the
> SYSTEM wrapper task is granted - user can execute whathever DotNet custom tas
> he wants. After the propsed changes SYTEM task authorization will no more.be
> performed. So DotNet custom code execution will become completeley
> unauthorised. We should fix it in a separate ticket.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18615) Implement events in java thin client
[ https://issues.apache.org/jira/browse/IGNITE-18615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-18615: --- Labels: important ise (was: ise) > Implement events in java thin client > > > Key: IGNITE-18615 > URL: https://issues.apache.org/jira/browse/IGNITE-18615 > Project: Ignite > Issue Type: Improvement > Components: thin client >Reporter: Ivan Daschinsky >Assignee: Ivan Daschinsky >Priority: Major > Labels: important, ise > Fix For: 2.15 > > Time Spent: 40m > Remaining Estimate: 0h > > I suggest to add monitoring capabilities similar to [java mongo > client|https://www.mongodb.com/docs/drivers/java/sync/current/fundamentals/monitoring] > I suggests to add listeners to: > # *Connection events* connect or disconnect to specific ignite server, > connection errors > # *Topology events* when partition awareness is enabled, log new topology > versions > # *Operations events* start,success or failure with request_id, server > (address, port and uuid), operation_id, error string if presents > This approach can implement custom metrics, tracing and other useful > client-side stuff in order to make client more observable -- 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 ] Aleksey Plekhanov updated IGNITE-17984: --- Labels: calcite calcite3-required iep-96 important (was: calcite calcite3-required iep-96) > 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, calcite3-required, 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-17351) Java thin: Implement logging
[ https://issues.apache.org/jira/browse/IGNITE-17351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-17351: --- Labels: important (was: ) > Java thin: Implement logging > > > Key: IGNITE-17351 > URL: https://issues.apache.org/jira/browse/IGNITE-17351 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Igor Sapego >Assignee: Pavel Tupitsyn >Priority: Major > Labels: important > Fix For: 2.15 > > Time Spent: 0.5h > Remaining Estimate: 0h > > We need to provide support for logging for Java thin client. > Make sure that it is easy to turn on full logging without re-compiling for > debugging purposes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18236) Cache objects transformation
[ https://issues.apache.org/jira/browse/IGNITE-18236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-18236: --- Labels: iep-97 important ise (was: iep-97 ise) > Cache objects transformation > > > Key: IGNITE-18236 > URL: https://issues.apache.org/jira/browse/IGNITE-18236 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: iep-97, important, ise > Fix For: 2.15 > > Time Spent: 3h 10m > Remaining Estimate: 0h > > See > [IEP-97|https://cwiki.apache.org/confluence/display/IGNITE/IEP-97+Cache+objects+transformation] > for details. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18591) Java thin client: Cluster discovery
[ https://issues.apache.org/jira/browse/IGNITE-18591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-18591: --- Labels: IEP-44 important ise (was: IEP-44 ise) > Java thin client: Cluster discovery > --- > > Key: IGNITE-18591 > URL: https://issues.apache.org/jira/browse/IGNITE-18591 > Project: Ignite > Issue Type: New Feature >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: IEP-44, important, ise > Fix For: 2.15 > > Time Spent: 20m > Remaining Estimate: 0h > > We already have cluster endpoints discovery in protocol and implementation > for .NET thin client. > Implementation for java thin client should be added too. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18637) Java thin client: Connections balancing
[ https://issues.apache.org/jira/browse/IGNITE-18637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-18637: --- Labels: important ise (was: ise) > Java thin client: Connections balancing > --- > > Key: IGNITE-18637 > URL: https://issues.apache.org/jira/browse/IGNITE-18637 > Project: Ignite > Issue Type: Improvement > Components: thin client >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: important, ise > Fix For: 2.15 > > Time Spent: 20m > Remaining Estimate: 0h > > Since Ignite 2.12 java thin client always connects to the first address from > the provided address list. In typical configuration this leads to overloading > an one server node and underloading other server nodes. > To improve workload distribution we can: > # Choose random first channel from the range of addresses with the same > (minimal) port. > # If partition awareness is enabled use random open channel instead of > default channel for operations which can't be mapped to a certain node. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17177) Implement incremental snapshots
[ https://issues.apache.org/jira/browse/IGNITE-17177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-17177: --- Labels: IEP-89 important ise (was: IEP-89 ise) > Implement incremental snapshots > --- > > Key: IGNITE-17177 > URL: https://issues.apache.org/jira/browse/IGNITE-17177 > Project: Ignite > Issue Type: New Feature >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: IEP-89, important, ise > Fix For: 2.15 > > Time Spent: 40m > Remaining Estimate: 0h > > Solution is incremental snapshots based on the Consistent Cut algorithm and > collecting WAL segments. > IEP-89: > https://cwiki.apache.org/confluence/display/IGNITE/IEP-89%3A+Incremental+Snapshots -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19139) Fix flaky ItDeployUndeployCallsTest
[ https://issues.apache.org/jira/browse/IGNITE-19139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vadim Pakhnushev reassigned IGNITE-19139: - Assignee: Vadim Pakhnushev > Fix flaky ItDeployUndeployCallsTest > --- > > Key: IGNITE-19139 > URL: https://issues.apache.org/jira/browse/IGNITE-19139 > Project: Ignite > Issue Type: Test >Reporter: Mikhail Pochatkin >Assignee: Vadim Pakhnushev >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19272) Uninformative jdbc failure after insertion into TIMESTAMP WITH LOCAL TIMEZONE
[
https://issues.apache.org/jira/browse/IGNITE-19272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17716802#comment-17716802
]
Evgeny Stanilovsky commented on IGNITE-19272:
-
probably we need to link them:
https://issues.apache.org/jira/browse/IGNITE-19292
> Uninformative jdbc failure after insertion into TIMESTAMP WITH LOCAL TIMEZONE
> -
>
> Key: IGNITE-19272
> URL: https://issues.apache.org/jira/browse/IGNITE-19272
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
>
> {code:java}
> try (Statement stmt = conn.createStatement()) {
> stmt.executeUpdate("CREATE TABLE timetest(id INT PRIMARY KEY,"
> + "ts TIMESTAMP, ts_tz TIMESTAMP WITH LOCAL TIME ZONE)");
> stmt.executeUpdate("INSERT INTO timetest VALUES "
> + "(3, '2011-01-01 01:01:01', TIMESTAMP WITH LOCAL TIME
> ZONE '2011-01-01 01:01:01')"); // <- ok
> stmt.executeUpdate("INSERT INTO timetest VALUES "
> + "(1, '2011-01-01 01:01:01', '2011-01-01 01:01:01')");
> // <- failed
> }
> {code}
> failed with no reason why:
> {noformat}
> java.sql.SQLException: Exception while executing query [query=INSERT INTO
> timetest VALUES (3, '2011-01-01 01:01:01', '2011-01-01 01:01:01')]. Error
> message:IGN-CMN-65535 TraceId:ba72bbc8-a0e3-414b-a520-6eed739b3f45 Remote
> query execution
> at
> org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57)
> at
> org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:148)
> at
> org.apache.ignite.internal.jdbc.JdbcStatement.executeUpdate(JdbcStatement.java:177)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-19272) Uninformative jdbc failure after insertion into TIMESTAMP WITH LOCAL TIMEZONE
[
https://issues.apache.org/jira/browse/IGNITE-19272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov reassigned IGNITE-19272:
-
Assignee: Andrey Mashenkov
> Uninformative jdbc failure after insertion into TIMESTAMP WITH LOCAL TIMEZONE
> -
>
> Key: IGNITE-19272
> URL: https://issues.apache.org/jira/browse/IGNITE-19272
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
>
> {code:java}
> try (Statement stmt = conn.createStatement()) {
> stmt.executeUpdate("CREATE TABLE timetest(id INT PRIMARY KEY,"
> + "ts TIMESTAMP, ts_tz TIMESTAMP WITH LOCAL TIME ZONE)");
> stmt.executeUpdate("INSERT INTO timetest VALUES "
> + "(3, '2011-01-01 01:01:01', TIMESTAMP WITH LOCAL TIME
> ZONE '2011-01-01 01:01:01')"); // <- ok
> stmt.executeUpdate("INSERT INTO timetest VALUES "
> + "(1, '2011-01-01 01:01:01', '2011-01-01 01:01:01')");
> // <- failed
> }
> {code}
> failed with no reason why:
> {noformat}
> java.sql.SQLException: Exception while executing query [query=INSERT INTO
> timetest VALUES (3, '2011-01-01 01:01:01', '2011-01-01 01:01:01')]. Error
> message:IGN-CMN-65535 TraceId:ba72bbc8-a0e3-414b-a520-6eed739b3f45 Remote
> query execution
> at
> org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57)
> at
> org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:148)
> at
> org.apache.ignite.internal.jdbc.JdbcStatement.executeUpdate(JdbcStatement.java:177)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-18817) Sql. Calcite 1.33.0+. TIMESTAMPDIFF requires modification.
[
https://issues.apache.org/jira/browse/IGNITE-18817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky resolved IGNITE-18817.
-
Resolution: Not A Problem
> Sql. Calcite 1.33.0+. TIMESTAMPDIFF requires modification.
> --
>
> Key: IGNITE-18817
> URL: https://issues.apache.org/jira/browse/IGNITE-18817
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: calcite2-required
>
> After updating to calcite 1.33.0 TIMESTAMPDIFF requires some updates as well
> otherwise we get an error.
> Query:
> {code:java}
> SELECT TIMESTAMPDIFF(SECOND, TIMESTAMP '2022-02-01 10:30:28.123', TIMESTAMP
> '2022-02-01 10:32:26')
> {code}
> Error:
> {code:java}
> Caused by: org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:1d8b4f81-efdf-4208-bff1-e90c607b3981 class
> org.apache.calcite.sql.SqlIntervalQualifier cannot be cast to class
> org.apache.calcite.sql.SqlLiteral
> (org.apache.calcite.sql.SqlIntervalQualifier and
> org.apache.calcite.sql.SqlLiteral are in unnamed module of loader 'app')
> at
> app//org.apache.ignite.lang.IgniteException.wrap(IgniteException.java:289)
> at app//org.apache.ignite.sql.Session.execute(Session.java:60)
> at
> app//org.apache.ignite.internal.sqllogic.ScriptContext.executeQuery(ScriptContext.java:89)
> at
> app//org.apache.ignite.internal.sqllogic.Query.execute(Query.java:263)
> at
> app//org.apache.ignite.internal.sqllogic.SqlScriptRunner.run(SqlScriptRunner.java:70)
> ... 6 more
> Caused by: java.lang.ClassCastException: class
> org.apache.calcite.sql.SqlIntervalQualifier cannot be cast to class
> org.apache.calcite.sql.SqlLiteral
> (org.apache.calcite.sql.SqlIntervalQualifier and
> org.apache.calcite.sql.SqlLiteral are in unnamed module of loader 'app')
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteConvertletTable$TimestampDiffConvertlet.convertCall(IgniteConvertletTable.java:69)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-19373) Get rid of waitForIndex() from tests
Yury Gerzhedovich created IGNITE-19373: -- Summary: Get rid of waitForIndex() from tests Key: IGNITE-19373 URL: https://issues.apache.org/jira/browse/IGNITE-19373 Project: Ignite Issue Type: Improvement Components: sql Reporter: Yury Gerzhedovich We have a crutch in our tests to wait to create indexes on all nodes in a cluster. Seems we already have other crutches to be ready to get rid of the first one. See the usage of org.apache.ignite.internal.sql.engine.ClusterPerClassIntegrationTest#waitForIndex -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19302) Phantom reads protection is broken
[
https://issues.apache.org/jira/browse/IGNITE-19302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov reassigned IGNITE-19302:
--
Assignee: Ivan Bessonov
> Phantom reads protection is broken
> --
>
> Key: IGNITE-19302
> URL: https://issues.apache.org/jira/browse/IGNITE-19302
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: ignite-3
>
> {{SortedIndexLocker#acquireLockNextKey}} is poorly implemented and not tested
> properly. It ignores the documented contract of {{hasNext}} and {{peek}} from
> {{{}PeekCursor{}}}.
> "Has next" checks must essentially be replaced with {{{}peek() != null{}}}.
> Unit tests, that would simulate concurrent operations, or maybe even do
> concurrent operations, must be implemented.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19371) Sql. Forbid TIME_WITH_LOCAL_TIME_ZONE and TIMESTAMP_WITH_LOCAL_TIME_ZONE data types.
[ https://issues.apache.org/jira/browse/IGNITE-19371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-19371: -- Component/s: sql > Sql. Forbid TIME_WITH_LOCAL_TIME_ZONE and TIMESTAMP_WITH_LOCAL_TIME_ZONE data > types. > > > Key: IGNITE-19371 > URL: https://issues.apache.org/jira/browse/IGNITE-19371 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > > Currently Ignite-3 do not take into account the client's/initiator's timezone > in any way. This will be resolved in IGNITE-19274. > We need to temporarily disable the use of these types: > * TIME_WITH_LOCAL_TIME_ZONE > * TIMESTAMP_WITH_LOCAL_TIME_ZONE > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19371) Sql. Forbid TIME_WITH_LOCAL_TIME_ZONE and TIMESTAMP_WITH_LOCAL_TIME_ZONE data types.
[ https://issues.apache.org/jira/browse/IGNITE-19371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-19371: -- Description: Currently Ignite-3 do not take into account the client's/initiator's timezone in any way. This will be resolved in IGNITE-19274. We need to temporarily disable the use of these types: * TIME_WITH_LOCAL_TIME_ZONE * TIMESTAMP_WITH_LOCAL_TIME_ZONE was: Currently Ignite-3 do not take into account the client's/initiator's timezone in any way. This will be resolved in IGNITE-19274. We need to temporarily disable the use of these types: * TIME_WITH_LOCAL_TIME_ZONE * TIMESTAMP_WITH_LOCAL_TIME_ZONE > Sql. Forbid TIME_WITH_LOCAL_TIME_ZONE and TIMESTAMP_WITH_LOCAL_TIME_ZONE data > types. > > > Key: IGNITE-19371 > URL: https://issues.apache.org/jira/browse/IGNITE-19371 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > > Currently Ignite-3 do not take into account the client's/initiator's timezone > in any way. This will be resolved in IGNITE-19274. > We need to temporarily disable the use of these types: > * TIME_WITH_LOCAL_TIME_ZONE > * TIMESTAMP_WITH_LOCAL_TIME_ZONE > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19371) Sql. Forbid TIME_WITH_LOCAL_TIME_ZONE and TIMESTAMP_WITH_LOCAL_TIME_ZONE data types.
[ https://issues.apache.org/jira/browse/IGNITE-19371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-19371: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Sql. Forbid TIME_WITH_LOCAL_TIME_ZONE and TIMESTAMP_WITH_LOCAL_TIME_ZONE data > types. > > > Key: IGNITE-19371 > URL: https://issues.apache.org/jira/browse/IGNITE-19371 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > > Currently Ignite-3 do not take into account the client's/initiator's timezone > in any way. > This will be resolved in IGNITE-19274. > We need to temporarily disable the use of these types: > * TIME_WITH_LOCAL_TIME_ZONE > * TIMESTAMP_WITH_LOCAL_TIME_ZONE > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19371) Sql. Forbid TIME_WITH_LOCAL_TIME_ZONE and TIMESTAMP_WITH_LOCAL_TIME_ZONE data types.
[
https://issues.apache.org/jira/browse/IGNITE-19371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-19371:
--
Description:
Currently Ignite-3 do not take into account the client's/initiator's timezone
in any way.
This will be resolved in IGNITE-19274.
We need to temporarily disable the use of these types:
TIME_WITH_LOCAL_TIME_ZONE
Apache Calcite supports the following "timezone aware" datatypes.
* TIMESTAMP WITH LOCAL TIME ZONE
* TIME WITH LOCAL TIME ZONE
The implementation is similar to Oracle "TIMESTAMP WITH LOCAL TIME ZONE" and
PostgreSQL "TIMESTAMP WITH TIME ZONE".
>From Oracle documentation:
"The TIMESTAMP WITH LOCAL TIME ZONE data type is a variant of TIMESTAMP that
includes a time zone offset in its value. Data stored in the database is
normalized to the database time zone (UTC) and time zone offset is not stored
as part of the column data. "
Usage example:
{noformat}
Client 1 (GMT+1)
insert time '11:00' -> stores '10:00' (in DB)
select time -> returns '11:00'
Client 2 (GMT+2)
select time -> returns '12:00'
{noformat}
*The problem - Ignite-3 do not take into account the client's/initiator's
timezone in any way.*
We have the following "data types mapping":
||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.Instant|yea|
*_WITH_LOCAL_TIME_ZONE types must take into account the client's local time
zone. Those. if the client is in the "GMT+3" time zone and is passing the value
"14:00", the value must be converted from GMT+3 to UTC and the value "11:00"
must be stored in the database.
h2. Proposal.
There are two implementation options, it all depends on when we will transfer
the client's time zone.
h2. 1. Transfer TimeZone from client per connection.
In this case the timezone from client will be stored per connection.
{code:java}
connect()
// save client's time zone to context/session
insert (time with local time zone '14:00')
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// transfer: value + timezone_offset
// returns: LocalTime
getTime()
// return value{code}
In this case all offsets will be applied on the server side, those
timestamp_with_time_zone we'll need to be LocalDateTime.
Since the timezone will only be set for each connection. Changing the client's
time zone during connection will have no effect.
E,g,
{code:java}
set timeZone='GMT+1'
connect()
insert (time with local time zone '14:00') // db stores '13:00'
select time -> returns '14:00'
set timeZone='GMT+2'
select time -> returns '14:00'
reconnect()
select time -> returns '15:00'{code}
As a result we'll have the following data types.
||Calcite type||JDBC Type||Current Ignite type||contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.LocalDateTime|no|
h2. 2. Transfer TimeZone from client per query.
In this case, we will need to add some special type instead of LocalTime
because it does not store timezone information.
Since we will have time zone information on the client, we will simply
translate the value to the local ghb time zone when it is displayed.
Those. the scheme of work is approximately the following.
{code:java}
connect()
insert (time with local time zone '14:00')
// put client's timezone from the request to execution context.
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// returns: LocalTimeTz
getTime()
// if (value instanceof LocalTimeTz)
// read UTC '11:00' + local_timezone_offset{code}
As a result we'll have the following types:
||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTimeTz|yes|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.Instant|yea|
But usually no one does this, the time zone is transmitted when connected to
the server.
And we need to separately discover how this approach will work with a Ignite
thin client.
was:
Currently Ignite-3 do not take into account the client's/initiator's timezone
in any way.
This will be resolved in IGNITE-19274.
We need to temporarily disable the use of these types:
Apache Calcite supports the following "timezone aware" datatypes.
* TIMESTAMP WITH LOCAL TIME ZONE
* TIME WITH LOCAL TI
[jira] [Updated] (IGNITE-19371) Sql. Forbid TIME_WITH_LOCAL_TIME_ZONE and TIMESTAMP_WITH_LOCAL_TIME_ZONE data types.
[
https://issues.apache.org/jira/browse/IGNITE-19371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-19371:
--
Description:
Currently Ignite-3 do not take into account the client's/initiator's timezone
in any way.
This will be resolved in IGNITE-19274.
We need to temporarily disable the use of these types:
* TIME_WITH_LOCAL_TIME_ZONE
* TIMESTAMP_WITH_LOCAL_TIME_ZONE
was:
Currently Ignite-3 do not take into account the client's/initiator's timezone
in any way.
This will be resolved in IGNITE-19274.
We need to temporarily disable the use of these types:
TIME_WITH_LOCAL_TIME_ZONE
Apache Calcite supports the following "timezone aware" datatypes.
* TIMESTAMP WITH LOCAL TIME ZONE
* TIME WITH LOCAL TIME ZONE
The implementation is similar to Oracle "TIMESTAMP WITH LOCAL TIME ZONE" and
PostgreSQL "TIMESTAMP WITH TIME ZONE".
>From Oracle documentation:
"The TIMESTAMP WITH LOCAL TIME ZONE data type is a variant of TIMESTAMP that
includes a time zone offset in its value. Data stored in the database is
normalized to the database time zone (UTC) and time zone offset is not stored
as part of the column data. "
Usage example:
{noformat}
Client 1 (GMT+1)
insert time '11:00' -> stores '10:00' (in DB)
select time -> returns '11:00'
Client 2 (GMT+2)
select time -> returns '12:00'
{noformat}
*The problem - Ignite-3 do not take into account the client's/initiator's
timezone in any way.*
We have the following "data types mapping":
||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.Instant|yea|
*_WITH_LOCAL_TIME_ZONE types must take into account the client's local time
zone. Those. if the client is in the "GMT+3" time zone and is passing the value
"14:00", the value must be converted from GMT+3 to UTC and the value "11:00"
must be stored in the database.
h2. Proposal.
There are two implementation options, it all depends on when we will transfer
the client's time zone.
h2. 1. Transfer TimeZone from client per connection.
In this case the timezone from client will be stored per connection.
{code:java}
connect()
// save client's time zone to context/session
insert (time with local time zone '14:00')
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// transfer: value + timezone_offset
// returns: LocalTime
getTime()
// return value{code}
In this case all offsets will be applied on the server side, those
timestamp_with_time_zone we'll need to be LocalDateTime.
Since the timezone will only be set for each connection. Changing the client's
time zone during connection will have no effect.
E,g,
{code:java}
set timeZone='GMT+1'
connect()
insert (time with local time zone '14:00') // db stores '13:00'
select time -> returns '14:00'
set timeZone='GMT+2'
select time -> returns '14:00'
reconnect()
select time -> returns '15:00'{code}
As a result we'll have the following data types.
||Calcite type||JDBC Type||Current Ignite type||contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.LocalDateTime|no|
h2. 2. Transfer TimeZone from client per query.
In this case, we will need to add some special type instead of LocalTime
because it does not store timezone information.
Since we will have time zone information on the client, we will simply
translate the value to the local ghb time zone when it is displayed.
Those. the scheme of work is approximately the following.
{code:java}
connect()
insert (time with local time zone '14:00')
// put client's timezone from the request to execution context.
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// returns: LocalTimeTz
getTime()
// if (value instanceof LocalTimeTz)
// read UTC '11:00' + local_timezone_offset{code}
As a result we'll have the following types:
||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTimeTz|yes|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.Instant|yea|
But usually no one does this, the time zone is transmitted when connected to
the server.
And we need to separately discover how this approach will work with a Ignite
thin client.
> Sql. Forbid TIME_WITH_LOCAL_TIME_ZONE and TIMESTAMP_WITH
[jira] [Updated] (IGNITE-19371) Sql. Forbid TIME_WITH_LOCAL_TIME_ZONE and TIMESTAMP_WITH_LOCAL_TIME_ZONE data types.
[
https://issues.apache.org/jira/browse/IGNITE-19371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-19371:
--
Description:
Currently Ignite-3 do not take into account the client's/initiator's timezone
in any way.
This will be resolved in IGNITE-19274.
We need to temporarily disable the use of these types:
Apache Calcite supports the following "timezone aware" datatypes.
* TIMESTAMP WITH LOCAL TIME ZONE
* TIME WITH LOCAL TIME ZONE
The implementation is similar to Oracle "TIMESTAMP WITH LOCAL TIME ZONE" and
PostgreSQL "TIMESTAMP WITH TIME ZONE".
>From Oracle documentation:
"The TIMESTAMP WITH LOCAL TIME ZONE data type is a variant of TIMESTAMP that
includes a time zone offset in its value. Data stored in the database is
normalized to the database time zone (UTC) and time zone offset is not stored
as part of the column data. "
Usage example:
{noformat}
Client 1 (GMT+1)
insert time '11:00' -> stores '10:00' (in DB)
select time -> returns '11:00'
Client 2 (GMT+2)
select time -> returns '12:00'
{noformat}
*The problem - Ignite-3 do not take into account the client's/initiator's
timezone in any way.*
We have the following "data types mapping":
||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.Instant|yea|
*_WITH_LOCAL_TIME_ZONE types must take into account the client's local time
zone. Those. if the client is in the "GMT+3" time zone and is passing the value
"14:00", the value must be converted from GMT+3 to UTC and the value "11:00"
must be stored in the database.
h2. Proposal.
There are two implementation options, it all depends on when we will transfer
the client's time zone.
h2. 1. Transfer TimeZone from client per connection.
In this case the timezone from client will be stored per connection.
{code:java}
connect()
// save client's time zone to context/session
insert (time with local time zone '14:00')
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// transfer: value + timezone_offset
// returns: LocalTime
getTime()
// return value{code}
In this case all offsets will be applied on the server side, those
timestamp_with_time_zone we'll need to be LocalDateTime.
Since the timezone will only be set for each connection. Changing the client's
time zone during connection will have no effect.
E,g,
{code:java}
set timeZone='GMT+1'
connect()
insert (time with local time zone '14:00') // db stores '13:00'
select time -> returns '14:00'
set timeZone='GMT+2'
select time -> returns '14:00'
reconnect()
select time -> returns '15:00'{code}
As a result we'll have the following data types.
||Calcite type||JDBC Type||Current Ignite type||contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.LocalDateTime|no|
h2. 2. Transfer TimeZone from client per query.
In this case, we will need to add some special type instead of LocalTime
because it does not store timezone information.
Since we will have time zone information on the client, we will simply
translate the value to the local ghb time zone when it is displayed.
Those. the scheme of work is approximately the following.
{code:java}
connect()
insert (time with local time zone '14:00')
// put client's timezone from the request to execution context.
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// returns: LocalTimeTz
getTime()
// if (value instanceof LocalTimeTz)
// read UTC '11:00' + local_timezone_offset{code}
As a result we'll have the following types:
||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTimeTz|yes|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.Instant|yea|
But usually no one does this, the time zone is transmitted when connected to
the server.
And we need to separately discover how this approach will work with a Ignite
thin client.
was:
Ignite-3 do not take into account the client's/initiator's timezone in any way.
This will be
Apache Calcite supports the following "timezone aware" datatypes.
* TIMESTAMP WITH LOCAL TIME ZONE
* TIME WITH LOCAL TIME ZONE
The implementation is similar to Oracle "TIMESTAMP WITH LOCAL TIME ZONE" and
PostgreSQL "TIMESTAMP WITH TIME Z
[jira] [Updated] (IGNITE-19371) Sql. Deprecate TIME_WITH_LOCAL_TIME_ZONE and TIMESTAMP_WITH_LOCAL_TIME_ZONE data types.
[
https://issues.apache.org/jira/browse/IGNITE-19371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-19371:
--
Description:
Ignite-3 do not take into account the client's/initiator's timezone in any way.
This will be
Apache Calcite supports the following "timezone aware" datatypes.
* TIMESTAMP WITH LOCAL TIME ZONE
* TIME WITH LOCAL TIME ZONE
The implementation is similar to Oracle "TIMESTAMP WITH LOCAL TIME ZONE" and
PostgreSQL "TIMESTAMP WITH TIME ZONE".
>From Oracle documentation:
"The TIMESTAMP WITH LOCAL TIME ZONE data type is a variant of TIMESTAMP that
includes a time zone offset in its value. Data stored in the database is
normalized to the database time zone (UTC) and time zone offset is not stored
as part of the column data. "
Usage example:
{noformat}
Client 1 (GMT+1)
insert time '11:00' -> stores '10:00' (in DB)
select time -> returns '11:00'
Client 2 (GMT+2)
select time -> returns '12:00'
{noformat}
*The problem - Ignite-3 do not take into account the client's/initiator's
timezone in any way.*
We have the following "data types mapping":
||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.Instant|yea|
*_WITH_LOCAL_TIME_ZONE types must take into account the client's local time
zone. Those. if the client is in the "GMT+3" time zone and is passing the value
"14:00", the value must be converted from GMT+3 to UTC and the value "11:00"
must be stored in the database.
h2. Proposal.
There are two implementation options, it all depends on when we will transfer
the client's time zone.
h2. 1. Transfer TimeZone from client per connection.
In this case the timezone from client will be stored per connection.
{code:java}
connect()
// save client's time zone to context/session
insert (time with local time zone '14:00')
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// transfer: value + timezone_offset
// returns: LocalTime
getTime()
// return value{code}
In this case all offsets will be applied on the server side, those
timestamp_with_time_zone we'll need to be LocalDateTime.
Since the timezone will only be set for each connection. Changing the client's
time zone during connection will have no effect.
E,g,
{code:java}
set timeZone='GMT+1'
connect()
insert (time with local time zone '14:00') // db stores '13:00'
select time -> returns '14:00'
set timeZone='GMT+2'
select time -> returns '14:00'
reconnect()
select time -> returns '15:00'{code}
As a result we'll have the following data types.
||Calcite type||JDBC Type||Current Ignite type||contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.LocalDateTime|no|
h2. 2. Transfer TimeZone from client per query.
In this case, we will need to add some special type instead of LocalTime
because it does not store timezone information.
Since we will have time zone information on the client, we will simply
translate the value to the local ghb time zone when it is displayed.
Those. the scheme of work is approximately the following.
{code:java}
connect()
insert (time with local time zone '14:00')
// put client's timezone from the request to execution context.
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// returns: LocalTimeTz
getTime()
// if (value instanceof LocalTimeTz)
// read UTC '11:00' + local_timezone_offset{code}
As a result we'll have the following types:
||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTimeTz|yes|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.Instant|yea|
But usually no one does this, the time zone is transmitted when connected to
the server.
And we need to separately discover how this approach will work with a Ignite
thin client.
was:
Apache Calcite supports the following "timezone aware" datatypes.
* TIMESTAMP WITH LOCAL TIME ZONE
* TIME WITH LOCAL TIME ZONE
The implementation is similar to Oracle "TIMESTAMP WITH LOCAL TIME ZONE" and
PostgreSQL "TIMESTAMP WITH TIME ZONE".
>From Oracle documentation:
"The TIMESTAMP WITH LOCAL TIME ZONE data type is a variant of TIMESTAMP that
includes a time zone offset in its value. Data stored in the database is
norma
[jira] [Updated] (IGNITE-19371) Sql. Forbid TIME_WITH_LOCAL_TIME_ZONE and TIMESTAMP_WITH_LOCAL_TIME_ZONE data types.
[
https://issues.apache.org/jira/browse/IGNITE-19371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-19371:
--
Summary: Sql. Forbid TIME_WITH_LOCAL_TIME_ZONE and
TIMESTAMP_WITH_LOCAL_TIME_ZONE data types. (was: Sql. Deprecate
TIME_WITH_LOCAL_TIME_ZONE and TIMESTAMP_WITH_LOCAL_TIME_ZONE data types.)
> Sql. Forbid TIME_WITH_LOCAL_TIME_ZONE and TIMESTAMP_WITH_LOCAL_TIME_ZONE data
> types.
>
>
> Key: IGNITE-19371
> URL: https://issues.apache.org/jira/browse/IGNITE-19371
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> Ignite-3 do not take into account the client's/initiator's timezone in any
> way.
> This will be
>
> Apache Calcite supports the following "timezone aware" datatypes.
> * TIMESTAMP WITH LOCAL TIME ZONE
> * TIME WITH LOCAL TIME ZONE
> The implementation is similar to Oracle "TIMESTAMP WITH LOCAL TIME ZONE" and
> PostgreSQL "TIMESTAMP WITH TIME ZONE".
> From Oracle documentation:
> "The TIMESTAMP WITH LOCAL TIME ZONE data type is a variant of TIMESTAMP that
> includes a time zone offset in its value. Data stored in the database is
> normalized to the database time zone (UTC) and time zone offset is not stored
> as part of the column data. "
> Usage example:
> {noformat}
> Client 1 (GMT+1)
> insert time '11:00' -> stores '10:00' (in DB)
> select time -> returns '11:00'
> Client 2 (GMT+2)
> select time -> returns '12:00'
> {noformat}
>
> *The problem - Ignite-3 do not take into account the client's/initiator's
> timezone in any way.*
> We have the following "data types mapping":
> ||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
> |TIME|java.sql.Time|java.time.LocalTime|no|
> |TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
> |TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
> |TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.Instant|yea|
> *_WITH_LOCAL_TIME_ZONE types must take into account the client's local time
> zone. Those. if the client is in the "GMT+3" time zone and is passing the
> value "14:00", the value must be converted from GMT+3 to UTC and the value
> "11:00" must be stored in the database.
> h2. Proposal.
> There are two implementation options, it all depends on when we will transfer
> the client's time zone.
> h2. 1. Transfer TimeZone from client per connection.
> In this case the timezone from client will be stored per connection.
> {code:java}
> connect()
> // save client's time zone to context/session
>
> insert (time with local time zone '14:00')
> // store: value - timezone_offset = '11:00' (UTC)
>
> select time with local time zone
> // read: value from DB '11:00' UTC
> // transfer: value + timezone_offset
> // returns: LocalTime
>
> getTime()
> // return value{code}
> In this case all offsets will be applied on the server side, those
> timestamp_with_time_zone we'll need to be LocalDateTime.
> Since the timezone will only be set for each connection. Changing the
> client's time zone during connection will have no effect.
> E,g,
> {code:java}
> set timeZone='GMT+1'
> connect()
> insert (time with local time zone '14:00') // db stores '13:00'
> select time -> returns '14:00'
> set timeZone='GMT+2'
> select time -> returns '14:00'
> reconnect()
> select time -> returns '15:00'{code}
> As a result we'll have the following data types.
> ||Calcite type||JDBC Type||Current Ignite type||contains timezone info||
> |TIME|java.sql.Time|java.time.LocalTime|no|
> |TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
> |TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
> |TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.LocalDateTime|no|
> h2. 2. Transfer TimeZone from client per query.
> In this case, we will need to add some special type instead of LocalTime
> because it does not store timezone information.
> Since we will have time zone information on the client, we will simply
> translate the value to the local ghb time zone when it is displayed.
>
> Those. the scheme of work is approximately the following.
> {code:java}
> connect()
>
> insert (time with local time zone '14:00')
> // put client's timezone from the request to execution context.
> // store: value - timezone_offset = '11:00' (UTC)
>
> select time with local time zone
> // read: value from DB '11:00' UTC
> // returns: LocalTimeTz
>
> getTime()
> // if (value instanceof LocalTimeTz)
> // read UTC '11:00' + local_timezone_offset{code}
> As a result we'll have the following types:
> ||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
> |TIME|java.sql.Time|java.time.LocalTime|no|
> |
[jira] [Comment Edited] (IGNITE-19274) Sql. Jdbc side working with TIMESTAMP WITH LOCAL TIME ZONE did not take into account current tz while storing data.
[
https://issues.apache.org/jira/browse/IGNITE-19274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17716595#comment-17716595
]
Pavel Pereslegin edited comment on IGNITE-19274 at 4/26/23 1:52 PM:
The issue described in the task is one of the problems in terms of supporting
work with the client's timezone.
*The problem - Ignite-3 do not take into account the client's/initiator's
timezone in any way.*
We have the following "data types mapping":
||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.Instant|yea|
*_WITH_LOCAL_TIME_ZONE types must take into account the client's local time
zone. Those. if the client is in the "GMT+3" time zone and is passing the value
"14:00", the value must be converted from GMT+3 to UTC and the value "11:00"
must be stored in the database.
h2. Proposal.
There are two implementation options, it all depends on when we will transfer
the client's time zone.
h2. 1. Transfer TimeZone from client per connection.
In this case the timezone from client will be stored per connection.
{code:java}
connect()
// save client's time zone to context/session
insert (time with local time zone '14:00')
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// transfer: value + timezone_offset
// returns: LocalTime
getTime()
// return value{code}
In this case all offsets will be applied on the server side, those
timestamp_with_time_zone we'll need to be LocalDateTime.
Since the timezone will only be set for each connection. Changing the client's
time zone during connection will have no effect.
E,g,
{code:java}
set timeZone='GMT+1'
connect()
insert (time with local time zone '14:00') // db stores '13:00'
select time -> returns '14:00'
set timeZone='GMT+2'
select time -> returns '14:00'
reconnect()
select time -> returns '15:00'{code}
As a result we'll have the following data types.
||Calcite type||JDBC Type||Current Ignite type||contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.LocalDateTime|no|
h2. 2. Transfer TimeZone from client per query.
In this case, we will need to add some special type instead of LocalTime
because it does not store timezone information.
Since we will have time zone information on the client, we will simply
translate the value to the local ghb time zone when it is displayed.
Those. the scheme of work is approximately the following.
{code:java}
connect()
insert (time with local time zone '14:00')
// put client's timezone from the request to execution context.
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// returns: LocalTimeTz
getTime()
// if (value instanceof LocalTimeTz)
// read UTC '11:00' + local_timezone_offset{code}
As a result we'll have the following types:
||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTimeTz|yes|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.Instant|yea|
But usually no one does this, the time zone is transmitted when connected to
the server.
And we need to separately discover how this approach will work with a Ignite
thin client.
was (Author: xtern):
The issue described in the task is one of the problems in terms of supporting
work with the client's timezone.
Currently we have the following types:
||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.Instant|yea|
*_WITH_LOCAL_TIME_ZONE types must take into account the client's local time
zone. Those. if the client is in the "GMT+3" time zone and is passing the value
"14:00", the value must be converted from GMT+3 to UTC and the value "11:00"
must be stored in the database.
Currently we do not take into account the client's/initiator's timezone in any
way.
h2. Proposal.
There are two implementation options, it all depends on when we will transfer
the client's time zone.
h2. 1. Transfer TimeZone from client per connection.
In this case the timezone fro
[jira] [Updated] (IGNITE-19371) Sql. Deprecate TIME_WITH_LOCAL_TIME_ZONE and TIMESTAMP_WITH_LOCAL_TIME_ZONE data types.
[
https://issues.apache.org/jira/browse/IGNITE-19371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-19371:
--
Summary: Sql. Deprecate TIME_WITH_LOCAL_TIME_ZONE and
TIMESTAMP_WITH_LOCAL_TIME_ZONE data types. (was: Sql. Provide support for
TIME_WITH_LOCAL_TIME_ZONE and TIMESTAMP_WITH_LOCAL_TIME_ZONE data types.)
> Sql. Deprecate TIME_WITH_LOCAL_TIME_ZONE and TIMESTAMP_WITH_LOCAL_TIME_ZONE
> data types.
> ---
>
> Key: IGNITE-19371
> URL: https://issues.apache.org/jira/browse/IGNITE-19371
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> Apache Calcite supports the following "timezone aware" datatypes.
> * TIMESTAMP WITH LOCAL TIME ZONE
> * TIME WITH LOCAL TIME ZONE
> The implementation is similar to Oracle "TIMESTAMP WITH LOCAL TIME ZONE" and
> PostgreSQL "TIMESTAMP WITH TIME ZONE".
> From Oracle documentation:
> "The TIMESTAMP WITH LOCAL TIME ZONE data type is a variant of TIMESTAMP that
> includes a time zone offset in its value. Data stored in the database is
> normalized to the database time zone (UTC) and time zone offset is not stored
> as part of the column data. "
> Usage example:
> {noformat}
> Client 1 (GMT+1)
> insert time '11:00' -> stores '10:00' (in DB)
> select time -> returns '11:00'
> Client 2 (GMT+2)
> select time -> returns '12:00'
> {noformat}
>
> *The problem - Ignite-3 do not take into account the client's/initiator's
> timezone in any way.*
> We have the following "data types mapping":
> ||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
> |TIME|java.sql.Time|java.time.LocalTime|no|
> |TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
> |TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
> |TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.Instant|yea|
> *_WITH_LOCAL_TIME_ZONE types must take into account the client's local time
> zone. Those. if the client is in the "GMT+3" time zone and is passing the
> value "14:00", the value must be converted from GMT+3 to UTC and the value
> "11:00" must be stored in the database.
> h2. Proposal.
> There are two implementation options, it all depends on when we will transfer
> the client's time zone.
> h2. 1. Transfer TimeZone from client per connection.
> In this case the timezone from client will be stored per connection.
> {code:java}
> connect()
> // save client's time zone to context/session
>
> insert (time with local time zone '14:00')
> // store: value - timezone_offset = '11:00' (UTC)
>
> select time with local time zone
> // read: value from DB '11:00' UTC
> // transfer: value + timezone_offset
> // returns: LocalTime
>
> getTime()
> // return value{code}
> In this case all offsets will be applied on the server side, those
> timestamp_with_time_zone we'll need to be LocalDateTime.
> Since the timezone will only be set for each connection. Changing the
> client's time zone during connection will have no effect.
> E,g,
> {code:java}
> set timeZone='GMT+1'
> connect()
> insert (time with local time zone '14:00') // db stores '13:00'
> select time -> returns '14:00'
> set timeZone='GMT+2'
> select time -> returns '14:00'
> reconnect()
> select time -> returns '15:00'{code}
> As a result we'll have the following data types.
> ||Calcite type||JDBC Type||Current Ignite type||contains timezone info||
> |TIME|java.sql.Time|java.time.LocalTime|no|
> |TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
> |TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
> |TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.LocalDateTime|no|
> h2. 2. Transfer TimeZone from client per query.
> In this case, we will need to add some special type instead of LocalTime
> because it does not store timezone information.
> Since we will have time zone information on the client, we will simply
> translate the value to the local ghb time zone when it is displayed.
>
> Those. the scheme of work is approximately the following.
> {code:java}
> connect()
>
> insert (time with local time zone '14:00')
> // put client's timezone from the request to execution context.
> // store: value - timezone_offset = '11:00' (UTC)
>
> select time with local time zone
> // read: value from DB '11:00' UTC
> // returns: LocalTimeTz
>
> getTime()
> // if (value instanceof LocalTimeTz)
> // read UTC '11:00' + local_timezone_offset{code}
> As a result we'll have the following types:
> ||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
> |TIME|java.sql.Time|java.time.LocalTime|no|
> |TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTimeTz|yes|
> |TIMESTAMP|java.
[jira] [Created] (IGNITE-19372) Ignite 3: Update docs for clients
Igor Gusev created IGNITE-19372: --- Summary: Ignite 3: Update docs for clients Key: IGNITE-19372 URL: https://issues.apache.org/jira/browse/IGNITE-19372 Project: Ignite Issue Type: Task Components: documentation Reporter: Igor Gusev There was a lot of changes to clients since beta release. We should go over the changes and put them in documentation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19371) Sql. Provide support for TIME_WITH_LOCAL_TIME_ZONE and TIMESTAMP_WITH_LOCAL_TIME_ZONE data types.
[
https://issues.apache.org/jira/browse/IGNITE-19371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-19371:
--
Description:
Apache Calcite supports the following "timezone aware" datatypes.
* TIMESTAMP WITH LOCAL TIME ZONE
* TIME WITH LOCAL TIME ZONE
The implementation is similar to Oracle "TIMESTAMP WITH LOCAL TIME ZONE" and
PostgreSQL "TIMESTAMP WITH TIME ZONE".
>From Oracle documentation:
"The TIMESTAMP WITH LOCAL TIME ZONE data type is a variant of TIMESTAMP that
includes a time zone offset in its value. Data stored in the database is
normalized to the database time zone (UTC) and time zone offset is not stored
as part of the column data. "
Usage example:
{noformat}
Client 1 (GMT+1)
insert time '11:00' -> stores '10:00' (in DB)
select time -> returns '11:00'
Client 2 (GMT+2)
select time -> returns '12:00'
{noformat}
*The problem - Ignite-3 do not take into account the client's/initiator's
timezone in any way.*
We have the following "data types mapping":
||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.Instant|yea|
*_WITH_LOCAL_TIME_ZONE types must take into account the client's local time
zone. Those. if the client is in the "GMT+3" time zone and is passing the value
"14:00", the value must be converted from GMT+3 to UTC and the value "11:00"
must be stored in the database.
h2. Proposal.
There are two implementation options, it all depends on when we will transfer
the client's time zone.
h2. 1. Transfer TimeZone from client per connection.
In this case the timezone from client will be stored per connection.
{code:java}
connect()
// save client's time zone to context/session
insert (time with local time zone '14:00')
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// transfer: value + timezone_offset
// returns: LocalTime
getTime()
// return value{code}
In this case all offsets will be applied on the server side, those
timestamp_with_time_zone we'll need to be LocalDateTime.
Since the timezone will only be set for each connection. Changing the client's
time zone during connection will have no effect.
E,g,
{code:java}
set timeZone='GMT+1'
connect()
insert (time with local time zone '14:00') // db stores '13:00'
select time -> returns '14:00'
set timeZone='GMT+2'
select time -> returns '14:00'
reconnect()
select time -> returns '15:00'{code}
As a result we'll have the following data types.
||Calcite type||JDBC Type||Current Ignite type||contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.LocalDateTime|no|
h2. 2. Transfer TimeZone from client per query.
In this case, we will need to add some special type instead of LocalTime
because it does not store timezone information.
Since we will have time zone information on the client, we will simply
translate the value to the local ghb time zone when it is displayed.
Those. the scheme of work is approximately the following.
{code:java}
connect()
insert (time with local time zone '14:00')
// put client's timezone from the request to execution context.
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// returns: LocalTimeTz
getTime()
// if (value instanceof LocalTimeTz)
// read UTC '11:00' + local_timezone_offset{code}
As a result we'll have the following types:
||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTimeTz|yes|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.Instant|yea|
But usually no one does this, the time zone is transmitted when connected to
the server.
And we need to separately discover how this approach will work with a Ignite
thin client.
was:
Apache Calcite supports the following "timezone aware" datatypes.
* TIMESTAMP WITH LOCAL TIME ZONE
* TIME WITH LOCAL TIME ZONE
The implementation is similar to Oracle "TIMESTAMP WITH LOCAL TIME ZONE" and
PostgreSQL "TIMESTAMP WITH TIME ZONE".
>From Oracle documentation:
"The TIMESTAMP WITH LOCAL TIME ZONE data type is a variant of TIMESTAMP that
includes a time zone offset in its value. Data stored in the database is
normalized to the database time zone (UTC) and time zone offset is not stored
as part of the column da
[jira] [Updated] (IGNITE-19371) Sql. Provide support for TIME_WITH_LOCAL_TIME_ZONE and TIMESTAMP_WITH_LOCAL_TIME_ZONE data types.
[
https://issues.apache.org/jira/browse/IGNITE-19371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-19371:
--
Summary: Sql. Provide support for TIME_WITH_LOCAL_TIME_ZONE and
TIMESTAMP_WITH_LOCAL_TIME_ZONE data types. (was: Sql. Provide support for the
TIME_WITH_LOCAL_TIME_ZONE and TIMESTAMP_WITH_LOCAL_TIME_ZONE data types.)
> Sql. Provide support for TIME_WITH_LOCAL_TIME_ZONE and
> TIMESTAMP_WITH_LOCAL_TIME_ZONE data types.
> -
>
> Key: IGNITE-19371
> URL: https://issues.apache.org/jira/browse/IGNITE-19371
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> Apache Calcite supports the following "timezone aware" datatypes.
> * TIMESTAMP WITH LOCAL TIME ZONE
> * TIME WITH LOCAL TIME ZONE
> The implementation is similar to Oracle "TIMESTAMP WITH LOCAL TIME ZONE" and
> PostgreSQL "TIMESTAMP WITH TIME ZONE".
> From Oracle documentation:
> "The TIMESTAMP WITH LOCAL TIME ZONE data type is a variant of TIMESTAMP that
> includes a time zone offset in its value. Data stored in the database is
> normalized to the database time zone (UTC) and time zone offset is not stored
> as part of the column data. "
> Usage example:
> {noformat}
> Client 1 (GMT+1)
> insert time '11:00' -> stores '10:00' (in DB)
> select time -> returns '11:00'
> Client 2 (GMT+2)
> select time -> returns '12:00'
> {noformat}
>
> *The problem - Ignite-3 do not take into account the client's/initiator's
> timezone in any way.*
> We have the following "data types mapping":
> ||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
> |TIME|java.sql.Time|java.time.LocalTime|no|
> |TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
> |TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
> |TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.Instant|yea|
> *_WITH_LOCAL_TIME_ZONE types must take into account the client's local time
> zone. Those. if the client is in the "GMT+3" time zone and is passing the
> value "14:00", the value must be converted from GMT+3 to UTC and the value
> "11:00" must be stored in the database.
> h2. Proposal.
> There are two implementation options, it all depends on when we will transfer
> the client's time zone.
> h2. 1. Transfer TimeZone from client per connection.
> In this case the timezone from client will be stored per connection.
> {code:java}
> connect()
> // save client's time zone to context/session
>
> insert (time with local time zone '14:00')
> // store: value - timezone_offset = '11:00' (UTC)
>
> select time with local time zone
> // read: value from DB '11:00' UTC
> // transfer: value + timezone_offset
> // returns: LocalTime
>
> getTime()
> // return value{code}
> In this case all offsets will be applied on the server side, those
> timestamp_with_time_zone we'll need to be LocalDateTime.
> Since the timezone will only be set for each connection. Changing the
> client's time zone during connection will have no effect.
> E,g,
> {code:java}
> set timeZone='GMT+1'
> connect()
> insert (time with local time zone '14:00') // db stores '13:00'
> select time -> returns '14:00'
> set timeZone='GMT+2'
> select time -> returns '14:00'
> reconnect()
> select time -> returns '15:00'{code}
> As a result we'll have the following data types.
> ||Calcite type||JDBC Type||Current Ignite type||contains timezone info||
> |TIME|java.sql.Time|java.time.LocalTime|no|
> |TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
> |TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
> |TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.LocalDateTime|no|
> h2. 2. Transfer TimeZone from client per query.
> In this case, we will need to add some special type instead of LocalTime
> because it does not store timezone information.
> Since we will have time zone information on the client, we will simply
> translate the value to the local ghb time zone when it is displayed.
>
> Those. the scheme of work is approximately the following.
> {code:java}
> connect()
>
> insert (time with local time zone '14:00')
> // put client's timezone from the request to execution context.
> // store: value - timezone_offset = '11:00' (UTC)
>
> select time with local time zone
> // read: value from DB '11:00' UTC
> // returns: LocalTimeTz
>
> getTime()
> // if (value instanceof LocalTimeTz)
> // read UTC '11:00' + local_timezone_offset{code}
> But usually no one does this, the time zone is transmitted when connected to
> the server.
> And we need to separately discover how it will work with a Ignite thin
> client.
--
This message was sent by Atlassian Jira
[jira] [Updated] (IGNITE-19339) Get rid of deprecated GridSslContextFactory at public API
[ https://issues.apache.org/jira/browse/IGNITE-19339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-19339: -- Fix Version/s: 2.16 > Get rid of deprecated GridSslContextFactory at public API > -- > > Key: IGNITE-19339 > URL: https://issues.apache.org/jira/browse/IGNITE-19339 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Fix For: 2.16 > > Time Spent: 20m > Remaining Estimate: 0h > > GridSslContextFactory deprecated since 2015, and it's time to get rid of it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19371) Sql. Provide support for the TIME_WITH_LOCAL_TIME_ZONE and TIMESTAMP_WITH_LOCAL_TIME_ZONE data types.
[
https://issues.apache.org/jira/browse/IGNITE-19371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-19371:
--
Description:
Apache Calcite supports the following "timezone aware" datatypes.
* TIMESTAMP WITH LOCAL TIME ZONE
* TIME WITH LOCAL TIME ZONE
The implementation is similar to Oracle "TIMESTAMP WITH LOCAL TIME ZONE" and
PostgreSQL "TIMESTAMP WITH TIME ZONE".
>From Oracle documentation:
"The TIMESTAMP WITH LOCAL TIME ZONE data type is a variant of TIMESTAMP that
includes a time zone offset in its value. Data stored in the database is
normalized to the database time zone (UTC) and time zone offset is not stored
as part of the column data. "
Usage example:
{noformat}
Client 1 (GMT+1)
insert time '11:00' -> stores '10:00' (in DB)
select time -> returns '11:00'
Client 2 (GMT+2)
select time -> returns '12:00'
{noformat}
*The problem - Ignite-3 do not take into account the client's/initiator's
timezone in any way.*
We have the following "data types mapping":
||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.Instant|yea|
*_WITH_LOCAL_TIME_ZONE types must take into account the client's local time
zone. Those. if the client is in the "GMT+3" time zone and is passing the value
"14:00", the value must be converted from GMT+3 to UTC and the value "11:00"
must be stored in the database.
h2. Proposal.
There are two implementation options, it all depends on when we will transfer
the client's time zone.
h2. 1. Transfer TimeZone from client per connection.
In this case the timezone from client will be stored per connection.
{code:java}
connect()
// save client's time zone to context/session
insert (time with local time zone '14:00')
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// transfer: value + timezone_offset
// returns: LocalTime
getTime()
// return value{code}
In this case all offsets will be applied on the server side, those
timestamp_with_time_zone we'll need to be LocalDateTime.
Since the timezone will only be set for each connection. Changing the client's
time zone during connection will have no effect.
E,g,
{code:java}
set timeZone='GMT+1'
connect()
insert (time with local time zone '14:00') // db stores '13:00'
select time -> returns '14:00'
set timeZone='GMT+2'
select time -> returns '14:00'
reconnect()
select time -> returns '15:00'{code}
As a result we'll have the following data types.
||Calcite type||JDBC Type||Current Ignite type||contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.LocalDateTime|no|
h2. 2. Transfer TimeZone from client per query.
In this case, we will need to add some special type instead of LocalTime
because it does not store timezone information.
Since we will have time zone information on the client, we will simply
translate the value to the local ghb time zone when it is displayed.
Those. the scheme of work is approximately the following.
{code:java}
connect()
insert (time with local time zone '14:00')
// put client's timezone from the request to execution context.
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// returns: LocalTimeTz
getTime()
// if (value instanceof LocalTimeTz)
// read UTC '11:00' + local_timezone_offset{code}
But usually no one does this, the time zone is transmitted when connected to
the server.
And we need to separately discover how it will work with a Ignite thin client.
was:
Apache Calcite supports the following "timezone aware" datatypes.
* TIMESTAMP WITH LOCAL TIME ZONE
* TIME WITH LOCAL TIME ZONE
The implementation is similar to Oracle "TIMESTAMP WITH LOCAL TIME ZONE" and
PostgreSQL "TIMESTAMP WITH TIME ZONE".
>From Oracle documentation:
"The TIMESTAMP WITH LOCAL TIME ZONE data type is a variant of TIMESTAMP that
includes a time zone offset in its value. Data stored in the database is
normalized to the database time zone (UTC) and time zone offset is not stored
as part of the column data. "
Usage example:
Client 1 (GMT+1)
insert time '11:00' -> stores '10:00' (in DB)
select time -> returns '11:00'
Client 2 (GMT+2)
select time -> returns '12:00'
*The problem - currently we do not take into account the client's/initiator's
timezone in any way.*
We have the following types:
||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
|
[jira] [Updated] (IGNITE-19371) Sql. Provide support for the TIME_WITH_LOCAL_TIME_ZONE and TIMESTAMP_WITH_LOCAL_TIME_ZONE data types.
[
https://issues.apache.org/jira/browse/IGNITE-19371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-19371:
--
Description:
Apache Calcite supports the following "timezone aware" datatypes.
* TIMESTAMP WITH LOCAL TIME ZONE
* TIME WITH LOCAL TIME ZONE
The implementation is similar to Oracle "TIMESTAMP WITH LOCAL TIME ZONE" and
PostgreSQL "TIMESTAMP WITH TIME ZONE".
>From Oracle documentation:
"The TIMESTAMP WITH LOCAL TIME ZONE data type is a variant of TIMESTAMP that
includes a time zone offset in its value. Data stored in the database is
normalized to the database time zone (UTC) and time zone offset is not stored
as part of the column data. "
Usage example:
Client 1 (GMT+1)
insert time '11:00' -> stores '10:00' (in DB)
select time -> returns '11:00'
Client 2 (GMT+2)
select time -> returns '12:00'
*The problem - currently we do not take into account the client's/initiator's
timezone in any way.*
We have the following types:
||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.Instant|yea|
*_WITH_LOCAL_TIME_ZONE types must take into account the client's local time
zone. Those. if the client is in the "GMT+3" time zone and is passing the value
"14:00", the value must be converted from GMT+3 to UTC and the value "11:00"
must be stored in the database.
h2. Proposal.
There are two implementation options, it all depends on when we will transfer
the client's time zone.
h2. 1. Transfer TimeZone from client per connection.
In this case the timezone from client will be stored per connection.
{code:java}
connect()
// save client's time zone to context/session
insert (time with local time zone '14:00')
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// transfer: value + timezone_offset
// returns: LocalTime
getTime()
// return value{code}
In this case all offsets will be applied on the server side, those
timestamp_with_time_zone we'll need to be LocalDateTime.
Since the timezone will only be set for each connection. Changing the client's
time zone during connection will have no effect.
E,g,
{code:java}
set timeZone='GMT+1'
connect()
insert (time with local time zone '14:00') // db stores '13:00'
select time -> returns '14:00'
set timeZone='GMT+2'
select time -> returns '14:00'
reconnect()
select time -> returns '15:00'{code}
As a result we'll have the following data types.
||Calcite type||JDBC Type||Current Ignite type||contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.LocalDateTime|no|
h2. 2. Transfer TimeZone from client per query.
In this case, we will need to add some special type instead of LocalTime
because it does not store timezone information.
Since we will have time zone information on the client, we will simply
translate the value to the local ghb time zone when it is displayed.
Those. the scheme of work is approximately the following.
{code:java}
connect()
insert (time with local time zone '14:00')
// put client's timezone from the request to execution context.
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// returns: LocalTimeTz
getTime()
// if (value instanceof LocalTimeTz)
// read UTC '11:00' + local_timezone_offset{code}
But usually no one does this, the time zone is transmitted when connected to
the server.
And we need to separately discover how it will work with a Ignite thin client.
was:
Apache Calcite supports the following "timezone aware" datatypes.
* TIMESTAMP WITH LOCAL TIME ZONE
* TIME WITH LOCAL TIME ZONE
The implementation is similar to Oracle "TIMESTAMP WITH LOCAL TIME ZONE" and
PostgreSQL "TIMESTAMP WITH TIME ZONE".
>From Oracle documentation:
"The TIMESTAMP WITH LOCAL TIME ZONE data type is a variant of TIMESTAMP that
includes a time zone offset in its value. Data stored in the database is
normalized to the database time zone (UTC) and time zone offset is not stored
as part of the column data. "
*The problem - currently we do not take into account the client's/initiator's
timezone in any way.*
We have the following types:
||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TI
[jira] [Updated] (IGNITE-19371) Sql. Provide support for the TIME_WITH_LOCAL_TIME_ZONE and TIMESTAMP_WITH_LOCAL_TIME_ZONE data types.
[
https://issues.apache.org/jira/browse/IGNITE-19371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-19371:
--
Description:
Apache Calcite supports the following "timezone aware" datatypes.
* TIMESTAMP WITH LOCAL TIME ZONE
* TIME WITH LOCAL TIME ZONE
The implementation is similar to Oracle "TIMESTAMP WITH LOCAL TIME ZONE" and
PostgreSQL "TIMESTAMP WITH TIME ZONE".
>From Oracle documentation:
"The TIMESTAMP WITH LOCAL TIME ZONE data type is a variant of TIMESTAMP that
includes a time zone offset in its value. Data stored in the database is
normalized to the database time zone (UTC) and time zone offset is not stored
as part of the column data. "
*The problem - currently we do not take into account the client's/initiator's
timezone in any way.*
We have the following types:
||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.Instant|yea|
*_WITH_LOCAL_TIME_ZONE types must take into account the client's local time
zone. Those. if the client is in the "GMT+3" time zone and is passing the value
"14:00", the value must be converted from GMT+3 to UTC and the value "11:00"
must be stored in the database.
h2. Proposal.
There are two implementation options, it all depends on when we will transfer
the client's time zone.
h2. 1. Transfer TimeZone from client per connection.
In this case the timezone from client will be stored per connection.
{code:java}
connect()
// save client's time zone to context/session
insert (time with local time zone '14:00')
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// transfer: value + timezone_offset
// returns: LocalTime
getTime()
// return value{code}
In this case all offsets will be applied on the server side, those
timestamp_with_time_zone we'll need to be LocalDateTime.
Since the timezone will only be set for each connection. Changing the client's
time zone during connection will have no effect.
E,g,
{code:java}
set timeZone='GMT+1'
connect()
insert (time with local time zone '14:00') // db stores '13:00'
select time -> returns '14:00'
set timeZone='GMT+2'
select time -> returns '14:00'
reconnect()
select time -> returns '15:00'{code}
As a result we'll have the following data types.
||Calcite type||JDBC Type||Current Ignite type||contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.LocalDateTime|no|
h2. 2. Transfer TimeZone from client per query.
In this case, we will need to add some special type instead of LocalTime
because it does not store timezone information.
Since we will have time zone information on the client, we will simply
translate the value to the local ghb time zone when it is displayed.
Those. the scheme of work is approximately the following.
{code:java}
connect()
insert (time with local time zone '14:00')
// put client's timezone from the request to execution context.
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// returns: LocalTimeTz
getTime()
// if (value instanceof LocalTimeTz)
// read UTC '11:00' + local_timezone_offset{code}
But usually no one does this, the time zone is transmitted when connected to
the server.
And we need to separately discover how it will work with a Ignite thin client.
was:
Apache Calcite supports the following "timezone aware" datatypes.
* TIMESTAMP WITH LOCAL TIME ZONE
* TIME WITH LOCAL TIME ZONE
The implementation is similar to Oracle "TIMESTAMP WITH LOCAL TIME ZONE" and
PostgreSQL "TIMESTAMP WITH TIME ZONE".
>From Oracle documentation:
"The TIMESTAMP WITH LOCAL TIME ZONE data type is a variant of TIMESTAMP that
includes a time zone offset in its value. Data stored in the database is
normalized to the database time zone (UTC) and time zone offset is not stored
as part of the column data. "
Currently we have the following types:
||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.Instant|yea|
*_WITH_LOCAL_TIME_ZONE types must take into account the client's local time
zone. Those. if the client is in the "GMT+3" time zone and is passing the value
"14:00", the value must be converted fro
[jira] [Updated] (IGNITE-19371) Sql. Provide support for the TIME_WITH_LOCAL_TIME_ZONE and TIMESTAMP_WITH_LOCAL_TIME_ZONE data types.
[
https://issues.apache.org/jira/browse/IGNITE-19371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-19371:
--
Description:
Apache Calcite supports the following "timezone aware" datatypes.
* TIMESTAMP WITH LOCAL TIME ZONE
* TIME WITH LOCAL TIME ZONE
The implementation is similar to Oracle "TIMESTAMP WITH LOCAL TIME ZONE" and
PostgreSQL "TIMESTAMP WITH TIME ZONE".
>From Oracle documentation:
"The TIMESTAMP WITH LOCAL TIME ZONE data type is a variant of TIMESTAMP that
includes a time zone offset in its value. Data stored in the database is
normalized to the database time zone (UTC) and time zone offset is not stored
as part of the column data. "
Currently we have the following types:
||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.Instant|yea|
*_WITH_LOCAL_TIME_ZONE types must take into account the client's local time
zone. Those. if the client is in the "GMT+3" time zone and is passing the value
"14:00", the value must be converted from GMT+3 to UTC and the value "11:00"
must be stored in the database.
The problem - currently we do not take into account the client's/initiator's
timezone in any way.
h2. Proposal.
There are two implementation options, it all depends on when we will transfer
the client's time zone.
h2. 1. Transfer TimeZone from client per connection.
In this case the timezone from client will be stored per connection.
{code:java}
connect()
// save client's time zone to context/session
insert (time with local time zone '14:00')
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// transfer: value + timezone_offset
// returns: LocalTime
getTime()
// return value{code}
In this case all offsets will be applied on the server side, those
timestamp_with_time_zone we'll need to be LocalDateTime.
Since the timezone will only be set for each connection. Changing the client's
time zone during connection will have no effect.
E,g,
{code:java}
set timeZone='GMT+1'
connect()
insert (time with local time zone '14:00') // db stores '13:00'
select time -> returns '14:00'
set timeZone='GMT+2'
select time -> returns '14:00'
reconnect()
select time -> returns '15:00'{code}
As a result we'll have the following data types.
||Calcite type||JDBC Type||Current Ignite type||contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.LocalDateTime|no|
h2. 2. Transfer TimeZone from client per query.
In this case, we will need to add some special type instead of LocalTime
because it does not store timezone information.
Since we will have time zone information on the client, we will simply
translate the value to the local ghb time zone when it is displayed.
Those. the scheme of work is approximately the following.
{code:java}
connect()
insert (time with local time zone '14:00')
// put client's timezone from the request to execution context.
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// returns: LocalTimeTz
getTime()
// if (value instanceof LocalTimeTz)
// read UTC '11:00' + local_timezone_offset{code}
But usually no one does this, the time zone is transmitted when connected to
the server.
And we need to separately discover how it will work with a Ignite thin client.
was:
Apache Calcite supports the following "timezone aware" datatypes.
* TIMESTAMP WITH LOCAL TIME ZONE
* TIME WITH LOCAL TIME ZONE
The implementation is similar to Oracle "TIMESTAMP WITH LOCAL TIME ZONE" and
PostgreSQL "TIMESTAMP WITH TIME ZONE".
>From Oracle documentation:
"The TIMESTAMP WITH LOCAL TIME ZONE data type is a variant of TIMESTAMP that
includes a time zone offset in its value. Data stored in the database is
normalized to the database time zone (UTC) and time zone offset is not stored
as part of the column data. "
The issue described in the task is one of the problems in terms of supporting
work with the client's timezone.
Currently we have the following types:
||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.Instant|yea|
*_WITH_LOCAL_TIME_ZONE types must take into account the client's local time
z
[jira] [Created] (IGNITE-19371) Sql. Provide support for the TIME_WITH_LOCAL_TIME_ZONE and TIMESTAMP_WITH_LOCAL_TIME_ZONE data types.
Pavel Pereslegin created IGNITE-19371:
-
Summary: Sql. Provide support for the TIME_WITH_LOCAL_TIME_ZONE
and TIMESTAMP_WITH_LOCAL_TIME_ZONE data types.
Key: IGNITE-19371
URL: https://issues.apache.org/jira/browse/IGNITE-19371
Project: Ignite
Issue Type: Improvement
Reporter: Pavel Pereslegin
Apache Calcite supports the following "timezone aware" datatypes.
* TIMESTAMP WITH LOCAL TIME ZONE
* TIME WITH LOCAL TIME ZONE
The implementation is similar to Oracle "TIMESTAMP WITH LOCAL TIME ZONE" and
PostgreSQL "TIMESTAMP WITH TIME ZONE".
>From Oracle documentation:
"The TIMESTAMP WITH LOCAL TIME ZONE data type is a variant of TIMESTAMP that
includes a time zone offset in its value. Data stored in the database is
normalized to the database time zone (UTC) and time zone offset is not stored
as part of the column data. "
The issue described in the task is one of the problems in terms of supporting
work with the client's timezone.
Currently we have the following types:
||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.Instant|yea|
*_WITH_LOCAL_TIME_ZONE types must take into account the client's local time
zone. Those. if the client is in the "GMT+3" time zone and is passing the value
"14:00", the value must be converted from GMT+3 to UTC and the value "11:00"
must be stored in the database.
Currently we do not take into account the client's/initiator's timezone in any
way.
h2. Proposal.
There are two implementation options, it all depends on when we will transfer
the client's time zone.
h2. 1. Transfer TimeZone from client per connection.
In this case the timezone from client will be stored per connection.
{code:java}
connect()
// save client's time zone to context/session
insert (time with local time zone '14:00')
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// transfer: value + timezone_offset
// returns: LocalTime
getTime()
// return value{code}
In this case all offsets will be applied on the server side, those
timestamp_with_time_zone we'll need to be LocalDateTime.
Since the timezone will only be set for each connection. Changing the client's
time zone during connection will have no effect.
E,g,
{code:java}
set timeZone='GMT+1'
connect()
insert (time with local time zone '14:00') // db stores '13:00'
select time -> returns '14:00'
set timeZone='GMT+2'
select time -> returns '14:00'
reconnect()
select time -> returns '15:00'{code}
As a result we'll have the following data types.
||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.LocalDateTime|no|
h2. 2. Transfer TimeZone from client per query.
In this case, we will need to add some special type instead of LocalTime
because it does not store timezone information.
Since we will have time zone information on the client, we will simply
translate the value to the local ghb time zone when it is displayed.
Those. the scheme of work is approximately the following.
{code:java}
connect()
insert (time with local time zone '14:00')
// put client's timezone from the request to execution context.
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// returns: LocalTimeTz
getTime()
// if (value instanceof LocalTimeTz)
// read UTC '11:00' + local_timezone_offset{code}
But usually no one does this, the time zone is transmitted when connected to
the server.
And we need to separately discover how it will work with a Ignite thin client.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19358) Sql. PrepareServiceImpl prepareDML cache does not take dynamic parameters into account
[
https://issues.apache.org/jira/browse/IGNITE-19358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-19358:
Labels: calcite3-required ignite-3 (was: ignite-3)
> Sql. PrepareServiceImpl prepareDML cache does not take dynamic parameters
> into account
> --
>
> Key: IGNITE-19358
> URL: https://issues.apache.org/jira/browse/IGNITE-19358
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-alpha2
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: calcite3-required, ignite-3
>
> PrepareService prepareDml cache does not take dynamic parameters into account
> which may leads to runtime errors when different queries reuse the same plan:
> {code:java}
> @Test
> public void test() {
> sql("SELECT ? + 1", 1);
> sql("SELECT ? + 1", 'X');
> }
> {code}
> Error:
> {code:java}
> IGN-CMN-65535 TraceId:028c3d10-1840-4fa4-bad2-d1ed8498654a class
> java.lang.Character cannot be cast to class java.lang.Integer
> (java.lang.Character and java.lang.Integer are in module java.base of loader
> 'bootstrap')
> org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:028c3d10-1840-4fa4-bad2-d1ed8498654a class java.lang.Character cannot
> be cast to class java.lang.Integer (java.lang.Character and java.lang.Integer
> are in module java.base of loader 'bootstrap')
> {code}
> Expected behaviour: dml plan cache should take dynamic parameters/types of
> dynamic parameters into account.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19358) Sql. PrepareServiceImpl prepareDML cache does not take dynamic parameters into account
[
https://issues.apache.org/jira/browse/IGNITE-19358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-19358:
Ignite Flags: (was: Docs Required,Release Notes Required)
> Sql. PrepareServiceImpl prepareDML cache does not take dynamic parameters
> into account
> --
>
> Key: IGNITE-19358
> URL: https://issues.apache.org/jira/browse/IGNITE-19358
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-alpha2
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> PrepareService prepareDml cache does not take dynamic parameters into account
> which may leads to runtime errors when different queries reuse the same plan:
> {code:java}
> @Test
> public void test() {
> sql("SELECT ? + 1", 1);
> sql("SELECT ? + 1", 'X');
> }
> {code}
> Error:
> {code:java}
> IGN-CMN-65535 TraceId:028c3d10-1840-4fa4-bad2-d1ed8498654a class
> java.lang.Character cannot be cast to class java.lang.Integer
> (java.lang.Character and java.lang.Integer are in module java.base of loader
> 'bootstrap')
> org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:028c3d10-1840-4fa4-bad2-d1ed8498654a class java.lang.Character cannot
> be cast to class java.lang.Integer (java.lang.Character and java.lang.Integer
> are in module java.base of loader 'bootstrap')
> {code}
> Expected behaviour: dml plan cache should take dynamic parameters/types of
> dynamic parameters into account.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19370) control.sh should be able to use custom SSL factory
[ https://issues.apache.org/jira/browse/IGNITE-19370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-19370: -- Labels: ise (was: ) > control.sh should be able to use custom SSL factory > --- > > Key: IGNITE-19370 > URL: https://issues.apache.org/jira/browse/IGNITE-19370 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: ise > Fix For: 2.16 > > Time Spent: 20m > Remaining Estimate: 0h > > Possible way is to add `--ssl-factory` option -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19370) control.sh should be able to use custom SSL factory
Anton Vinogradov created IGNITE-19370: - Summary: control.sh should be able to use custom SSL factory Key: IGNITE-19370 URL: https://issues.apache.org/jira/browse/IGNITE-19370 Project: Ignite Issue Type: Improvement Reporter: Anton Vinogradov Assignee: Anton Vinogradov Possible way is to add `--ssl-factory` option -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19370) control.sh should be able to use custom SSL factory
[ https://issues.apache.org/jira/browse/IGNITE-19370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-19370: -- Fix Version/s: 2.16 > control.sh should be able to use custom SSL factory > --- > > Key: IGNITE-19370 > URL: https://issues.apache.org/jira/browse/IGNITE-19370 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Fix For: 2.16 > > > Possible way is to add `--ssl-factory` option -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19242) .NET: Thin 3.0: propagate table schema updates to client on write-only operations
[
https://issues.apache.org/jira/browse/IGNITE-19242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17716681#comment-17716681
]
Igor Sapego commented on IGNITE-19242:
--
Let's put this ticket on hold for now as there is an issue that this ticket are
not solving.
The problem: client receives new schema version (if any) on every tuple
operation with the given table. However, this is too late:
# var view = client.tables().table("FOO").recordView(); view.upsert(...) - now
client knows schema v1
# client.sql().exec("ALTER TABLE FOO ADD COLUMN NEWCOL INT"); - client alters
the table, but does not know about schema v2 with new column
# view.upsert(Tuple.create().set("key", 1).set("NEWCOL", 100)) - v1 is used to
send data to the server, NEWCOL is ignored, data is lost. Response says that
schema v2 is available, but alas.
> .NET: Thin 3.0: propagate table schema updates to client on write-only
> operations
> -
>
> Key: IGNITE-19242
> URL: https://issues.apache.org/jira/browse/IGNITE-19242
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Currently, .NET client receives table schema updates when write-read requests
> are performed. For example, client performs TUPLE_GET request, sends key
> tuple using old schema version, receives result tuple with the latest schema
> version, and retrieves the latest schema.
> However, some requests are "write-only": client sends a tuple, but does not
> receive one back, like TUPLE_UPSERT. No schema updates are performed in this
> case.
> To fix this, include the latest schema version into all write-only operation
> responses:
> * TUPLE_UPSERT
> * TUPLE_UPSERT_ALL
> * TUPLE_INSERT
> * TUPLE_INSERT_ALL
> * TUPLE_REPLACE
> * TUPLE_REPLACE_EXACT
> * TUPLE_DELETE
> * TUPLE_DELETE_ALL
> * TUPLE_DELETE_EXACT
> * TUPLE_DELETE_ALL_EXACT
> * TUPLE_CONTAINS_KEY
> Client will compare this version to the known one and perform a background
> update, if necessary.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19269) Introduce proper local RowId locks
[
https://issues.apache.org/jira/browse/IGNITE-19269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-19269:
---
Ignite Flags: (was: Docs Required,Release Notes Required)
Reviewer: Roman Puchkovskiy
> Introduce proper local RowId locks
> --
>
> Key: IGNITE-19269
> URL: https://issues.apache.org/jira/browse/IGNITE-19269
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, concurrency in MV storages is a bit convoluted. List of issues
> include:
> * Implicit assumption that one does not insert the same RowId concurrently.
> There's a chance that this assumption is already violated. This could lead to
> B+Tree corruptions, for example.
> * Hidden locks, that cause non-trivial bugs like this:
> https://issues.apache.org/jira/browse/IGNITE-19169
> * MvPartitionStorage#scanVersions implementation for B+Tree reads the entire
> chain at once, because we couldn't figure out how to do it properly in
> concurrent environment. This may lead to drastic performance drops in the
> future.
> * GC code is complicated and sub-optimal. We need to implement the same
> approach that's used in Ignite 2.x - read, lock, dequeue, cleanup, unlock*.
> We can also cache part of the queue beforehand, making the process faster. It
> is not possible in current implementation.
> * Maybe something else that I couldn't remember.
> h3. Proposed solution
> As wise man once said, "{_}Explicit is better than implicit{_}".
> I propose having an explicit concurrency model akin Ignite 2.x's. We need to
> introduce 2 new methods to MV partition storage interface.
> {code:java}
> /**
> * Synchronously locks passed RowId.
> */
> void lock(RowId rowId);
> /**
> * Tries to synchronously lock passed RowId.
> * Used to implement deadlock prevention.
> */
> boolean tryLock(RowId rowId);{code}
> These methods should delegate locking to the client, basically exposing the
> {{ReentrantLockByRowId}} API. Expected invariants:
> * Locks can only be allowed inside of the "runConsistently" closure.
> * Unlock is still supposed to happen at the end of "runConsistently",
> automatically. This is predicated by the way RocksDB implementation works
> (batches).
> Client must guarantee, that there are no deadlocks, either by sorting the
> data or by using "tryLock".
> * All read operations, except for "scanVersions", may be executed without
> locks.
> * "scanVersions" must have a lock, because it's not atomic. This is not a
> big deal, because the only two usages are:
> ** index cleanup, we already hold a lock
> ** rebalance, we already hold another lock, so adding a new one is not a
> problem
> * "scanVersions" implementation must also be fixed. Maybe we need to add a
> hint, like "loadAllVersions", but it's not required.
> This approach, with proper implementation, solves all mentioned problems,
> except for GC.
> h3. Changes to GC
> As stated before, GC flow must be changed to something like this:
> {code:java}
> var entry = partition.peek(lw);
> if (entry == null) {
> return;
> }
> if (!partition.tryLock(entry.rowId())) {
> return; // Must exit closure to avoid deadlocks.
> }
> if (!partition.dequeue(entry)) {
> continue; // Or return. We may or may not exit the closure
> // in this case, both options are valid.
> }
> cleanupIndexes(entry);
> continue;{code}
> Right now, all storage implementations have similar construction inside of
> them. All I propose is to move it outside.
> h3. Tangent changes
> org.apache.ignite.internal.table.distributed.raft.PartitionDataStorage is
> basically a copy of the original, except for a few methods. Maybe copied
> methods should exist in a shared super-interface. It's up to developer to
> decide.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19369) Metadata topic offset must be stored only after commit
[
https://issues.apache.org/jira/browse/IGNITE-19369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-19369:
-
Issue Type: Bug (was: Improvement)
> Metadata topic offset must be stored only after commit
> --
>
> Key: IGNITE-19369
> URL: https://issues.apache.org/jira/browse/IGNITE-19369
> Project: Ignite
> Issue Type: Bug
> Components: extensions
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Blocker
> Labels: IEP-59, ise
>
> Improvement of {{KafkaToIgniteMetadataUpdater}} lead to error when data not
> returned to the consumer from the topic.
> Read offsets must be stored only after consumer#commit successfully.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19369) Metadata topic offset must be stored only after commit
[
https://issues.apache.org/jira/browse/IGNITE-19369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-19369:
-
Description:
Improvement of {{KafkaToIgniteMetadataUpdater}} lead to error when data not
returned to the consumer from the topic.
Read offsets must be stored only after consumer#commit successfully.
was:
Currently, when CDC through Kafka is used there are possible delays in
replication between clusters when {{KafkaToIgniteCdcStreamerApplier}} tries to
update binary metadata and marshaller mappings.
Delays caused by calls of {{KafkaConsumer#poll}} in
{{KafkaToIgniteMetadataUpdater#updateMetadata}} , when meta topic is empty:
# When first {{KafkaToIgniteCdcStreamerApplier}} meets {{META_UPDATE_MARKER}}
it calls {{KafkaToIgniteMetadataUpdater#updateMetadata}} which in turn calls
{{KafkaConsumer#poll}}, which returns immediately [1] when data is present in
metadata topic. If there are few binary types and mappings to update, first
{{KafkaToIgniteCdcStreamerApplier}} will consume all entries from metadata
topic.
# {{KafkaToIgniteCdcStreamerApplier}} consequently call
{{KafkaToIgniteMetadataUpdater#updateMetadata}} for each partition with meta
update marker. All further consequent calls will wait for {{kafkaReqTimeout}}.
# Also there is a bottleneck, when multiple applier threads tries to update
metadata and call synchronized method
{{KafkaToIgniteMetadataUpdater#updateMetadata}}, because
{{KafkaToIgniteMetadataUpdater}} is shared between applier threads.
# Because {{META_UPDATE_MARKER}} is sent twice to each Kafka partition of event
topic from every node: firstly, in case of type mappings updates, secondly, in
case of binary types update there are possible delays up to {{clusterSize x
(topicPartitions x 2 - 1) x kafkaReqTimeout}}.
# Data updates are blocked for Kafka partitions with unprocessed update markers.
# For example for default timeout and 16 Kafka partitions _last partition will
be consumed after 1.5 minutes_ in case of two one-node clusters.
Links:
#
[https://kafka.apache.org/27/javadoc/org/apache/kafka/clients/consumer/KafkaConsumer.html#poll-java.time.Duration-]
> Metadata topic offset must be stored only after commit
> --
>
> Key: IGNITE-19369
> URL: https://issues.apache.org/jira/browse/IGNITE-19369
> Project: Ignite
> Issue Type: Improvement
> Components: extensions
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Blocker
> Labels: IEP-59, ise
>
> Improvement of {{KafkaToIgniteMetadataUpdater}} lead to error when data not
> returned to the consumer from the topic.
> Read offsets must be stored only after consumer#commit successfully.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-19369) metadata topic offset must be stored only after commit
Nikolay Izhikov created IGNITE-19369:
Summary: metadata topic offset must be stored only after commit
Key: IGNITE-19369
URL: https://issues.apache.org/jira/browse/IGNITE-19369
Project: Ignite
Issue Type: Improvement
Components: extensions
Reporter: Ilya Shishkov
Assignee: Ilya Shishkov
Currently, when CDC through Kafka is used there are possible delays in
replication between clusters when {{KafkaToIgniteCdcStreamerApplier}} tries to
update binary metadata and marshaller mappings.
Delays caused by calls of {{KafkaConsumer#poll}} in
{{KafkaToIgniteMetadataUpdater#updateMetadata}} , when meta topic is empty:
# When first {{KafkaToIgniteCdcStreamerApplier}} meets {{META_UPDATE_MARKER}}
it calls {{KafkaToIgniteMetadataUpdater#updateMetadata}} which in turn calls
{{KafkaConsumer#poll}}, which returns immediately [1] when data is present in
metadata topic. If there are few binary types and mappings to update, first
{{KafkaToIgniteCdcStreamerApplier}} will consume all entries from metadata
topic.
# {{KafkaToIgniteCdcStreamerApplier}} consequently call
{{KafkaToIgniteMetadataUpdater#updateMetadata}} for each partition with meta
update marker. All further consequent calls will wait for {{kafkaReqTimeout}}.
# Also there is a bottleneck, when multiple applier threads tries to update
metadata and call synchronized method
{{KafkaToIgniteMetadataUpdater#updateMetadata}}, because
{{KafkaToIgniteMetadataUpdater}} is shared between applier threads.
# Because {{META_UPDATE_MARKER}} is sent twice to each Kafka partition of event
topic from every node: firstly, in case of type mappings updates, secondly, in
case of binary types update there are possible delays up to {{clusterSize x
(topicPartitions x 2 - 1) x kafkaReqTimeout}}.
# Data updates are blocked for Kafka partitions with unprocessed update markers.
# For example for default timeout and 16 Kafka partitions _last partition will
be consumed after 1.5 minutes_ in case of two one-node clusters.
Links:
#
[https://kafka.apache.org/27/javadoc/org/apache/kafka/clients/consumer/KafkaConsumer.html#poll-java.time.Duration-]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19369) Metadata topic offset must be stored only after commit
[
https://issues.apache.org/jira/browse/IGNITE-19369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-19369:
-
Reporter: Nikolay Izhikov (was: Ilya Shishkov)
> Metadata topic offset must be stored only after commit
> --
>
> Key: IGNITE-19369
> URL: https://issues.apache.org/jira/browse/IGNITE-19369
> Project: Ignite
> Issue Type: Improvement
> Components: extensions
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Minor
> Labels: IEP-59, ise
>
> Currently, when CDC through Kafka is used there are possible delays in
> replication between clusters when {{KafkaToIgniteCdcStreamerApplier}} tries
> to update binary metadata and marshaller mappings.
> Delays caused by calls of {{KafkaConsumer#poll}} in
> {{KafkaToIgniteMetadataUpdater#updateMetadata}} , when meta topic is empty:
> # When first {{KafkaToIgniteCdcStreamerApplier}} meets {{META_UPDATE_MARKER}}
> it calls {{KafkaToIgniteMetadataUpdater#updateMetadata}} which in turn calls
> {{KafkaConsumer#poll}}, which returns immediately [1] when data is present in
> metadata topic. If there are few binary types and mappings to update, first
> {{KafkaToIgniteCdcStreamerApplier}} will consume all entries from metadata
> topic.
> # {{KafkaToIgniteCdcStreamerApplier}} consequently call
> {{KafkaToIgniteMetadataUpdater#updateMetadata}} for each partition with meta
> update marker. All further consequent calls will wait for
> {{kafkaReqTimeout}}.
> # Also there is a bottleneck, when multiple applier threads tries to update
> metadata and call synchronized method
> {{KafkaToIgniteMetadataUpdater#updateMetadata}}, because
> {{KafkaToIgniteMetadataUpdater}} is shared between applier threads.
> # Because {{META_UPDATE_MARKER}} is sent twice to each Kafka partition of
> event topic from every node: firstly, in case of type mappings updates,
> secondly, in case of binary types update there are possible delays up to
> {{clusterSize x (topicPartitions x 2 - 1) x kafkaReqTimeout}}.
> # Data updates are blocked for Kafka partitions with unprocessed update
> markers.
> # For example for default timeout and 16 Kafka partitions _last partition
> will be consumed after 1.5 minutes_ in case of two one-node clusters.
> Links:
> #
> [https://kafka.apache.org/27/javadoc/org/apache/kafka/clients/consumer/KafkaConsumer.html#poll-java.time.Duration-]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19369) Metadata topic offset must be stored only after commit
[
https://issues.apache.org/jira/browse/IGNITE-19369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-19369:
-
Summary: Metadata topic offset must be stored only after commit (was:
metadata topic offset must be stored only after commit)
> Metadata topic offset must be stored only after commit
> --
>
> Key: IGNITE-19369
> URL: https://issues.apache.org/jira/browse/IGNITE-19369
> Project: Ignite
> Issue Type: Improvement
> Components: extensions
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Labels: IEP-59, ise
>
> Currently, when CDC through Kafka is used there are possible delays in
> replication between clusters when {{KafkaToIgniteCdcStreamerApplier}} tries
> to update binary metadata and marshaller mappings.
> Delays caused by calls of {{KafkaConsumer#poll}} in
> {{KafkaToIgniteMetadataUpdater#updateMetadata}} , when meta topic is empty:
> # When first {{KafkaToIgniteCdcStreamerApplier}} meets {{META_UPDATE_MARKER}}
> it calls {{KafkaToIgniteMetadataUpdater#updateMetadata}} which in turn calls
> {{KafkaConsumer#poll}}, which returns immediately [1] when data is present in
> metadata topic. If there are few binary types and mappings to update, first
> {{KafkaToIgniteCdcStreamerApplier}} will consume all entries from metadata
> topic.
> # {{KafkaToIgniteCdcStreamerApplier}} consequently call
> {{KafkaToIgniteMetadataUpdater#updateMetadata}} for each partition with meta
> update marker. All further consequent calls will wait for
> {{kafkaReqTimeout}}.
> # Also there is a bottleneck, when multiple applier threads tries to update
> metadata and call synchronized method
> {{KafkaToIgniteMetadataUpdater#updateMetadata}}, because
> {{KafkaToIgniteMetadataUpdater}} is shared between applier threads.
> # Because {{META_UPDATE_MARKER}} is sent twice to each Kafka partition of
> event topic from every node: firstly, in case of type mappings updates,
> secondly, in case of binary types update there are possible delays up to
> {{clusterSize x (topicPartitions x 2 - 1) x kafkaReqTimeout}}.
> # Data updates are blocked for Kafka partitions with unprocessed update
> markers.
> # For example for default timeout and 16 Kafka partitions _last partition
> will be consumed after 1.5 minutes_ in case of two one-node clusters.
> Links:
> #
> [https://kafka.apache.org/27/javadoc/org/apache/kafka/clients/consumer/KafkaConsumer.html#poll-java.time.Duration-]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-19369) Metadata topic offset must be stored only after commit
[
https://issues.apache.org/jira/browse/IGNITE-19369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov reassigned IGNITE-19369:
Assignee: Nikolay Izhikov (was: Ilya Shishkov)
> Metadata topic offset must be stored only after commit
> --
>
> Key: IGNITE-19369
> URL: https://issues.apache.org/jira/browse/IGNITE-19369
> Project: Ignite
> Issue Type: Improvement
> Components: extensions
>Reporter: Ilya Shishkov
>Assignee: Nikolay Izhikov
>Priority: Minor
> Labels: IEP-59, ise
>
> Currently, when CDC through Kafka is used there are possible delays in
> replication between clusters when {{KafkaToIgniteCdcStreamerApplier}} tries
> to update binary metadata and marshaller mappings.
> Delays caused by calls of {{KafkaConsumer#poll}} in
> {{KafkaToIgniteMetadataUpdater#updateMetadata}} , when meta topic is empty:
> # When first {{KafkaToIgniteCdcStreamerApplier}} meets {{META_UPDATE_MARKER}}
> it calls {{KafkaToIgniteMetadataUpdater#updateMetadata}} which in turn calls
> {{KafkaConsumer#poll}}, which returns immediately [1] when data is present in
> metadata topic. If there are few binary types and mappings to update, first
> {{KafkaToIgniteCdcStreamerApplier}} will consume all entries from metadata
> topic.
> # {{KafkaToIgniteCdcStreamerApplier}} consequently call
> {{KafkaToIgniteMetadataUpdater#updateMetadata}} for each partition with meta
> update marker. All further consequent calls will wait for
> {{kafkaReqTimeout}}.
> # Also there is a bottleneck, when multiple applier threads tries to update
> metadata and call synchronized method
> {{KafkaToIgniteMetadataUpdater#updateMetadata}}, because
> {{KafkaToIgniteMetadataUpdater}} is shared between applier threads.
> # Because {{META_UPDATE_MARKER}} is sent twice to each Kafka partition of
> event topic from every node: firstly, in case of type mappings updates,
> secondly, in case of binary types update there are possible delays up to
> {{clusterSize x (topicPartitions x 2 - 1) x kafkaReqTimeout}}.
> # Data updates are blocked for Kafka partitions with unprocessed update
> markers.
> # For example for default timeout and 16 Kafka partitions _last partition
> will be consumed after 1.5 minutes_ in case of two one-node clusters.
> Links:
> #
> [https://kafka.apache.org/27/javadoc/org/apache/kafka/clients/consumer/KafkaConsumer.html#poll-java.time.Duration-]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19369) Metadata topic offset must be stored only after commit
[
https://issues.apache.org/jira/browse/IGNITE-19369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-19369:
-
Priority: Blocker (was: Minor)
> Metadata topic offset must be stored only after commit
> --
>
> Key: IGNITE-19369
> URL: https://issues.apache.org/jira/browse/IGNITE-19369
> Project: Ignite
> Issue Type: Improvement
> Components: extensions
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Blocker
> Labels: IEP-59, ise
>
> Currently, when CDC through Kafka is used there are possible delays in
> replication between clusters when {{KafkaToIgniteCdcStreamerApplier}} tries
> to update binary metadata and marshaller mappings.
> Delays caused by calls of {{KafkaConsumer#poll}} in
> {{KafkaToIgniteMetadataUpdater#updateMetadata}} , when meta topic is empty:
> # When first {{KafkaToIgniteCdcStreamerApplier}} meets {{META_UPDATE_MARKER}}
> it calls {{KafkaToIgniteMetadataUpdater#updateMetadata}} which in turn calls
> {{KafkaConsumer#poll}}, which returns immediately [1] when data is present in
> metadata topic. If there are few binary types and mappings to update, first
> {{KafkaToIgniteCdcStreamerApplier}} will consume all entries from metadata
> topic.
> # {{KafkaToIgniteCdcStreamerApplier}} consequently call
> {{KafkaToIgniteMetadataUpdater#updateMetadata}} for each partition with meta
> update marker. All further consequent calls will wait for
> {{kafkaReqTimeout}}.
> # Also there is a bottleneck, when multiple applier threads tries to update
> metadata and call synchronized method
> {{KafkaToIgniteMetadataUpdater#updateMetadata}}, because
> {{KafkaToIgniteMetadataUpdater}} is shared between applier threads.
> # Because {{META_UPDATE_MARKER}} is sent twice to each Kafka partition of
> event topic from every node: firstly, in case of type mappings updates,
> secondly, in case of binary types update there are possible delays up to
> {{clusterSize x (topicPartitions x 2 - 1) x kafkaReqTimeout}}.
> # Data updates are blocked for Kafka partitions with unprocessed update
> markers.
> # For example for default timeout and 16 Kafka partitions _last partition
> will be consumed after 1.5 minutes_ in case of two one-node clusters.
> Links:
> #
> [https://kafka.apache.org/27/javadoc/org/apache/kafka/clients/consumer/KafkaConsumer.html#poll-java.time.Duration-]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-19242) .NET: Thin 3.0: propagate table schema updates to client on write-only operations
[ https://issues.apache.org/jira/browse/IGNITE-19242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17716657#comment-17716657 ] Pavel Tupitsyn commented on IGNITE-19242: - [~isapego] please review. > .NET: Thin 3.0: propagate table schema updates to client on write-only > operations > - > > Key: IGNITE-19242 > URL: https://issues.apache.org/jira/browse/IGNITE-19242 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Currently, .NET client receives table schema updates when write-read requests > are performed. For example, client performs TUPLE_GET request, sends key > tuple using old schema version, receives result tuple with the latest schema > version, and retrieves the latest schema. > However, some requests are "write-only": client sends a tuple, but does not > receive one back, like TUPLE_UPSERT. No schema updates are performed in this > case. > To fix this, include the latest schema version into all write-only operation > responses: > * TUPLE_UPSERT > * TUPLE_UPSERT_ALL > * TUPLE_INSERT > * TUPLE_INSERT_ALL > * TUPLE_REPLACE > * TUPLE_REPLACE_EXACT > * TUPLE_DELETE > * TUPLE_DELETE_ALL > * TUPLE_DELETE_EXACT > * TUPLE_DELETE_ALL_EXACT > * TUPLE_CONTAINS_KEY > Client will compare this version to the known one and perform a background > update, if necessary. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19306) Drop multiple column if exists without brace
[
https://issues.apache.org/jira/browse/IGNITE-19306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Gusev reassigned IGNITE-19306:
---
Assignee: Igor Gusev
> Drop multiple column if exists without brace
>
>
> Key: IGNITE-19306
> URL: https://issues.apache.org/jira/browse/IGNITE-19306
> Project: Ignite
> Issue Type: Bug
> Components: documentation
>Affects Versions: 3.0
>Reporter: Alexander Belyak
>Assignee: Igor Gusev
>Priority: Trivial
> Labels: ignite-3
>
> Wrong parameter name {{IF NOT EXISTS}}
> [https://ignite.apache.org/docs/3.0.0-beta/sql-reference/ddl#alter-table-if-exists-table-drop-column-if-exists-column1-column2-int]
> Correct one: IF EXISTS
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-19049) Apache Ignite Blog Migration
[ https://issues.apache.org/jira/browse/IGNITE-19049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erlan Aytpaev resolved IGNITE-19049. Resolution: Fixed > Apache Ignite Blog Migration > > > Key: IGNITE-19049 > URL: https://issues.apache.org/jira/browse/IGNITE-19049 > Project: Ignite > Issue Type: Task > Components: website >Reporter: Kseniya Romanova >Assignee: Erlan Aytpaev >Priority: Major > > Due to INFRA upcoming changes, we need to move the blog from ASF website to > the Apache Ignite website. > Design discussion: > https://lists.apache.org/thread/sc3lly1pq5gdzq9v5s8ycngvtobnyq5d > We need to: > 1) Create a blog with URL ignite.apache.org/blog > 2) Move here all the posts from the old blog https://blogs.apache.org/ignite/ > 3)Make some changes to the upper menu: > - Remove the "Resources" item from the "Get Started" menu > - Add "Learning Resources" and "Training and Courses" from > https://ignite.apache.org/resources.html (these are very relevant to the > getting started process) > - Add to the upper menu the "Resources" item (let's put it between "Powered > by" and "Docs") with the "Blog" item highlighted (I guess, we need set > anchors on the resources page to create this drop-down menu). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19363) Split start of indexes and start of partition raft group nodes
[ https://issues.apache.org/jira/browse/IGNITE-19363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semyon Danilov updated IGNITE-19363: Description: Right now there is a cyclic dependency between raft group nodes recovery on start and start of indexes. To start indexes all raft nodes should be started. And raft nodes perform index rebuild on start. Index rebuild is a blocking operation which waits for the table to appear. That can't happen until all raft nodes started. As there's a smaller number of stripes in disruptor, blocking one disruptor block the start of another raft node, so table can't appear and index rebuild can't be finished. > Split start of indexes and start of partition raft group nodes > -- > > Key: IGNITE-19363 > URL: https://issues.apache.org/jira/browse/IGNITE-19363 > Project: Ignite > Issue Type: Improvement >Reporter: Semyon Danilov >Priority: Major > Labels: ignite-3 > > Right now there is a cyclic dependency between raft group nodes recovery on > start and start of indexes. To start indexes all raft nodes should be > started. And raft nodes perform index rebuild on start. Index rebuild is a > blocking operation which waits for the table to appear. That can't happen > until all raft nodes started. As there's a smaller number of stripes in > disruptor, blocking one disruptor block the start of another raft node, so > table can't appear and index rebuild can't be finished. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-19189) Ignite node re-writes configuration file on start
[
https://issues.apache.org/jira/browse/IGNITE-19189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr resolved IGNITE-19189.
Resolution: Won't Fix
The issue is fixed in IGNITE-19152
> Ignite node re-writes configuration file on start
> -
>
> Key: IGNITE-19189
> URL: https://issues.apache.org/jira/browse/IGNITE-19189
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Bessonov
>Assignee: Aleksandr
>Priority: Major
> Labels: ignite-3
>
> The way it works right now:
> * we start the node
> * we read the content of configuration file
> * we apply the content as a single change
> * this change is writing the content back into file
> This makes it impossible to run the node with read-only configuration file.
> I think that making {{LocalFileConfigurationStorage}} aware of the bootstrap
> procedure is not too bad of a solution. Basically, all we need is to ignore
> the first call of {{{}LocalFileConfigurationStorage#saveValues{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-19368) Fix ignite-cdc-ext assembly
[ https://issues.apache.org/jira/browse/IGNITE-19368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Shishkov reassigned IGNITE-19368: -- Assignee: (was: Ilya Shishkov) > Fix ignite-cdc-ext assembly > --- > > Key: IGNITE-19368 > URL: https://issues.apache.org/jira/browse/IGNITE-19368 > Project: Ignite > Issue Type: Bug > Components: extensions >Reporter: Ilya Shishkov >Priority: Major > Labels: IEP-59, ise > > Currently, _kafka-clients_ and _slf4j-api_ libraries are missing in the > assembled zip file. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19368) Fix ignite-cdc-ext assembly
[
https://issues.apache.org/jira/browse/IGNITE-19368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-19368:
---
Description: Currently, _kafka-clients_ and _slf4j-api_ libraries are
missing in the assembled zip file. (was: CDC though Kafka uses
{{KafkaConsumer}} and {{KafkaProducer}}, which are parts of {{kafka-clients}}
module.
But when you build ignite-cdc-ext with a below command:
{code}
mvn clean package -f modules/cdc-ext/ -P checkstyle,extension-release
-DskipTests
{code}
you will obtain zip file with a structure [^ignite-cdc-ext-current.txt], where
{{kafka-clients}} dependency _*is missing*_.
So, when you try to start {{KafkaToIgniteCdcStreamer}} or
{{IgniteToKafkaCdcStreamer}} you will obtain missing classes error.
Building of module changed after IGNITE-16847, IGNITE-16815. Structure was:
[^ignite-cdc-ext-old.txt]. As you can see, there was many jar libraries
included, but i'm not sure whether all of them needed to run CDC.
I have prepared a patch [^cdc-ext-build-patch.patch], which replaces
_kafka_2.12-2.7.0.jar_ by _kafka-clients-2.7.0.jar_ and tested it locally:
problems with missed classes eliminated and it seems, that simple active-active
replication cases works fine. But, patch does not fix other dependencies from
old build assembly structure (I'm not sure, that all dependencies satisfied).
Structure after patch: [^ignite-cdc-ext-patch.txt]
Also, proposed patch affects other modules, which uses
{{/assembly/bin-component-shared.xml}} in build process.)
> Fix ignite-cdc-ext assembly
> ---
>
> Key: IGNITE-19368
> URL: https://issues.apache.org/jira/browse/IGNITE-19368
> Project: Ignite
> Issue Type: Bug
> Components: extensions
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Major
> Labels: IEP-59, ise
>
> Currently, _kafka-clients_ and _slf4j-api_ libraries are missing in the
> assembled zip file.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-19368) Fix ignite-cdc-ext assembly
Ilya Shishkov created IGNITE-19368:
--
Summary: Fix ignite-cdc-ext assembly
Key: IGNITE-19368
URL: https://issues.apache.org/jira/browse/IGNITE-19368
Project: Ignite
Issue Type: Bug
Components: extensions
Reporter: Ilya Shishkov
Assignee: Ilya Shishkov
CDC though Kafka uses {{KafkaConsumer}} and {{KafkaProducer}}, which are parts
of {{kafka-clients}} module.
But when you build ignite-cdc-ext with a below command:
{code}
mvn clean package -f modules/cdc-ext/ -P checkstyle,extension-release
-DskipTests
{code}
you will obtain zip file with a structure [^ignite-cdc-ext-current.txt], where
{{kafka-clients}} dependency _*is missing*_.
So, when you try to start {{KafkaToIgniteCdcStreamer}} or
{{IgniteToKafkaCdcStreamer}} you will obtain missing classes error.
Building of module changed after IGNITE-16847, IGNITE-16815. Structure was:
[^ignite-cdc-ext-old.txt]. As you can see, there was many jar libraries
included, but i'm not sure whether all of them needed to run CDC.
I have prepared a patch [^cdc-ext-build-patch.patch], which replaces
_kafka_2.12-2.7.0.jar_ by _kafka-clients-2.7.0.jar_ and tested it locally:
problems with missed classes eliminated and it seems, that simple active-active
replication cases works fine. But, patch does not fix other dependencies from
old build assembly structure (I'm not sure, that all dependencies satisfied).
Structure after patch: [^ignite-cdc-ext-patch.txt]
Also, proposed patch affects other modules, which uses
{{/assembly/bin-component-shared.xml}} in build process.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-19274) Sql. Jdbc side working with TIMESTAMP WITH LOCAL TIME ZONE did not take into account current tz while storing data.
[
https://issues.apache.org/jira/browse/IGNITE-19274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17716595#comment-17716595
]
Pavel Pereslegin edited comment on IGNITE-19274 at 4/26/23 8:34 AM:
The issue described in the task is one of the problems in terms of supporting
work with the client's timezone.
Currently we have the following types:
||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.Instant|yea|
*_WITH_LOCAL_TIME_ZONE types must take into account the client's local time
zone. Those. if the client is in the "GMT+3" time zone and is passing the value
"14:00", the value must be converted from GMT+3 to UTC and the value "11:00"
must be stored in the database.
Currently we do not take into account the client's/initiator's timezone in any
way.
h2. Proposal.
There are two implementation options, it all depends on when we will transfer
the client's time zone.
h2. 1. Transfer TimeZone from client per connection.
In this case the timezone from client will be stored per connection.
{code:java}
connect()
// save client's time zone to context/session
insert (time with local time zone '14:00')
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// transfer: value + timezone_offset
// returns: LocalTime
getTime()
// return value{code}
In this case all offsets will be applied on the server side, those
timestamp_with_time_zone we'll need to be LocalDateTime.
Since the timezone will only be set for each connection. Changing the client's
time zone during connection will have no effect.
E,g,
{code:java}
set timeZone='GMT+1'
connect()
insert (time with local time zone '14:00') // db stores '13:00'
select time -> returns '14:00'
set timeZone='GMT+2'
select time -> returns '14:00'
reconnect()
select time -> returns '15:00'{code}
h2. 2. Transfer TimeZone from client per query.
In this case, we will need to add some special type instead of LocalTime
because it does not store timezone information.
Since we will have time zone information on the client, we will simply
translate the value to the local ghb time zone when it is displayed.
Those. the scheme of work is approximately the following.
{code:java}
connect()
insert (time with local time zone '14:00')
// put client's timezone from the request to execution context.
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// returns: LocalTimeTz
getTime()
// if (value instanceof LocalTimeTz)
// read UTC '11:00' + local_timezone_offset{code}
But usually no one does this, the time zone is transmitted when connected to
the server.
And we need to separately discover how it will work with a Ignite thin client.
was (Author: xtern):
The issue described in the task is one of the problems in terms of supporting
work with the client's timezone.
Currently we have the following types:
||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.Instant|yea|
*_WITH_LOCAL_TIME_ZONE types must take into account the client's local time
zone. Those. if the client is in the "GMT+3" time zone and is passing the value
"14:00", the value must be converted from GMT+3 to UTC and the value "11:00"
must be stored in the database.
Currently we do not take into account the client's/initiator's timezone in any
way.
h2. Proposal.
There are two implementation options, it all depends on when we will transfer
the client's time zone.
h2. 1. Transfer TimeZone from client per connection.
In this case the timezone from client will be stored per connection.
{code:java}
connect()
// save client's time zone to context/session
insert (time with local time zone '14:00')
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// transfer: value + timezone_offset
// returns: LocalTime
getTime()
// return value{code}
In this case all offsets will be applied on the server side, those
timestamp_with_time_zone we'll need to be LocalDateTime.
Since the timezone will only be set for each connection. Changing the client's
time zone during connection will have no effect.
E,g,
{code:java}
set timeZone='GMT+1'
connect()
insert (time with local time zone '14:00')
select time -> retur
[jira] [Comment Edited] (IGNITE-19274) Sql. Jdbc side working with TIMESTAMP WITH LOCAL TIME ZONE did not take into account current tz while storing data.
[
https://issues.apache.org/jira/browse/IGNITE-19274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17716595#comment-17716595
]
Pavel Pereslegin edited comment on IGNITE-19274 at 4/26/23 8:32 AM:
The issue described in the task is one of the problems in terms of supporting
work with the client's timezone.
Currently we have the following types:
||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.Instant|yea|
*_WITH_LOCAL_TIME_ZONE types must take into account the client's local time
zone. Those. if the client is in the "GMT+3" time zone and is passing the value
"14:00", the value must be converted from GMT+3 to UTC and the value "11:00"
must be stored in the database.
Currently we do not take into account the client's/initiator's timezone in any
way.
h2. Proposal.
There are two implementation options, it all depends on when we will transfer
the client's time zone.
h2. 1. Transfer TimeZone from client per connection.
In this case the timezone from client will be stored per connection.
{code:java}
connect()
// save client's time zone to context/session
insert (time with local time zone '14:00')
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// transfer: value + timezone_offset
// returns: LocalTime
getTime()
// return value{code}
In this case all offsets will be applied on the server side, those
timestamp_with_time_zone we'll need to be LocalDateTime.
Since the timezone will only be set for each connection. Changing the client's
time zone during connection will have no effect.
E,g,
{code:java}
set timeZone='GMT+1'
connect()
insert (time with local time zone '14:00')
select time -> returns '14:00'
set timeZone='GMT+2'
select time -> returns '14:00'
reconnect()
select time -> returns '15:00'{code}
h2. 2. Transfer TimeZone from client per query.
In this case, we will need to add some special type instead of LocalTime
because it does not store timezone information.
Since we will have time zone information on the client, we will simply
translate the value to the local ghb time zone when it is displayed.
Those. the scheme of work is approximately the following.
{code:java}
connect()
insert (time with local time zone '14:00')
// put client's timezone from the request to execution context.
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// returns: LocalTimeTz
getTime()
// if (value instanceof LocalTimeTz)
// read UTC '11:00' + local_timezone_offset{code}
But usually no one does this, the time zone is transmitted when connected to
the server.
And we need to separately discover how it will work with a Ignite thin client.
was (Author: xtern):
The issue described in the task is one of the problems in terms of supporting
work with the client's timezone.
Currently we have the following types:
||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.Instant|yea|
*_WITH_LOCAL_TIME_ZONE types must take into account the client's local time
zone. Those. if the client is in the "GMT+3" time zone and is passing the value
"14:00", the value must be converted from GMT+3 to UTC and the value "11:00"
must be stored in the database.
Currently we do not take into account the client's/initiator's timezone in any
way.
h2. Proposal.
There are two implementation options, it all depends on when we will transfer
the client's time zone.
h2. 1. Transfer TimeZone from client per connection.
In this case the timezone from client will be stored per connection.
{code:java}
connect()
// save client's time zone to context/session
insert (time with local time zone '14:00')
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// transfer: value + timezone_offset
// returns: LocalTime
getTime()
// return value{code}
In this case all offsets will be applied on the server side, those
timestamp_with_time_zone we'll need to be LocalDateTime.
Since the timezone will only be set for each connection. Changing the client's
time zone during connection will have no effect.
E,g,
{code:java}
set timeZone='GMT+1'
connect()
insert (time with local time zone '14:00')
select time -> returns '14:00'
set timeZo
[jira] [Comment Edited] (IGNITE-19274) Sql. Jdbc side working with TIMESTAMP WITH LOCAL TIME ZONE did not take into account current tz while storing data.
[
https://issues.apache.org/jira/browse/IGNITE-19274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17716595#comment-17716595
]
Pavel Pereslegin edited comment on IGNITE-19274 at 4/26/23 8:32 AM:
The issue described in the task is one of the problems in terms of supporting
work with the client's timezone.
Currently we have the following types:
||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.Instant|yea|
*_WITH_LOCAL_TIME_ZONE types must take into account the client's local time
zone. Those. if the client is in the "GMT+3" time zone and is passing the value
"14:00", the value must be converted from GMT+3 to UTC and the value "11:00"
must be stored in the database.
Currently we do not take into account the client's/initiator's timezone in any
way.
h2. Proposal.
There are two implementation options, it all depends on when we will transfer
the client's time zone.
h2. 1. Transfer TimeZone from client per connection.
In this case the timezone from client will be stored per connection.
{code:java}
connect()
// save client's time zone to context/session
insert (time with local time zone '14:00')
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// transfer: value + timezone_offset
// returns: LocalTime
getTime()
// return value{code}
In this case all offsets will be applied on the server side, those
timestamp_with_time_zone we'll need to be LocalDateTime.
Since the timezone will only be set for each connection. Changing the client's
time zone during connection will have no effect.
E,g,
{code:java}
set timeZone='GMT+1'
connect()
insert (time with local time zone '14:00')
select time -> returns '14:00'
set timeZone='GMT+2'
select time -> returns '14:00'
reconnect()
select time -> returns '15:00'{code}
h2. 2. Transfer TimeZone from client per query.
In this case, we will need to add some special type instead of LocalTime
because it does not store timezone information.
Since we will have time zone information on the client, we will simply
translate the value to the local ghb time zone when it is displayed.
Those. the scheme of work is approximately the following.
{code:java}
connect()
insert (time with local time zone '14:00')
// put client's timezone from the request to execution context.
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// returns: LocalTimeTz
getTime()
// if (value instanceof LocalTimeTz)
// read UTC '11:00' + local_timezone_offset{code}
But usually no one does this, the time zone is transmitted when connected to
the server.
And we need to separately discover how it will work with a Ignite thin client.
was (Author: xtern):
The issue described in the task is one of the problems in terms of supporting
work with the client's timezone.
Currently we have the following types:
||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.Instant|yea|
*_WITH_LOCAL_TIME_ZONE types must take into account the client's local time
zone. Those. if the client is in the "GMT+3" time zone and is passing the value
"14:00", the value must be converted from GMT+3 to UTC and the value "11:00"
must be stored in the database.
Currently we do not take into account the client's/initiator's timezone in any
way.
h2. Proposal.
There are two implementation options, it all depends on when we will transfer
the client's time zone.
h2. 1. Transfer TimeZone from client per connection.
In this case the timezone from client will be stored per connection.
{code:java}
connect()
// save client's time zone to context/session
insert (time with local time zone '14:00')
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// transfer: value + timezone_offset
// returns: LocalTime
getTime()
// return value{code}
In this case all offsets will be applied on the server side, those
timestamp_with_time_zone we'll need to be LocalDateTime.
Since the timezone will only be set for each connection. Changing the client's
time zone during connection will have no effect.
E,g,
{code:java}
set timeZone='GMT+1'
connect()
insert (time with local time zone '14:00')
select time -> returns '14:00'
set time
[jira] [Updated] (IGNITE-19365) Disable components until the cluster configuration is applied
[ https://issues.apache.org/jira/browse/IGNITE-19365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-19365: --- Description: There are instances where the Ignite 3 component requires to be "enabled" when the cluster configuration is applied. The lifecycle of the component can be adjusted to follow these steps: creating the component, starting the component, *waiting for the required cluster configuration, and enabling the component*. One particular example is the REST component, which needs to be configured with basic authentication. There is a time-lapse between cluster initialization and applying the authentication configuration. During this time, the REST API remains unauthenticated, and the cluster endpoints are available to everyone, as mentioned in the IGNITE-18943 ticket. The component needs to be started -> the cluster must be initialized -> basic auth cluster configuration should be applied -> REST is enabled. Redesign of the Ignite 3 component lifecycle is a part of this issue. was: There are instances where the Ignite 3 component requires to be "enabled" when the cluster configuration is applied. The lifecycle of the component can be adjusted to follow these steps: creating the component, starting the component, *waiting for the required cluster configuration, and enabling the component*. One particular example is the REST component, which needs to be configured with basic authentication. There is a time-lapse between cluster initialization and applying the authentication configuration. During this time, the REST API remains unauthenticated, and the cluster endpoints are available to everyone, as mentioned in the IGNITE-18943 ticket. The component needs to be started -> the cluster must be initialized -> but basic auth cluster configuration should be applied -> REST is enabled. Redesign of the Ignite 3 component lifecycle is a part of this issue. > Disable components until the cluster configuration is applied > - > > Key: IGNITE-19365 > URL: https://issues.apache.org/jira/browse/IGNITE-19365 > Project: Ignite > Issue Type: New Feature > Components: clients, rest >Reporter: Vadim Pakhnushev >Priority: Major > Labels: ignite-3 > > There are instances where the Ignite 3 component requires to be "enabled" > when the cluster configuration is applied. The lifecycle of the component can > be adjusted to follow these steps: creating the component, starting the > component, *waiting for the required cluster configuration, and enabling the > component*. > One particular example is the REST component, which needs to be configured > with basic authentication. There is a time-lapse between cluster > initialization and applying the authentication configuration. During this > time, the REST API remains unauthenticated, and the cluster endpoints are > available to everyone, as mentioned in the IGNITE-18943 ticket. The component > needs to be started -> the cluster must be initialized -> basic auth cluster > configuration should be applied -> REST is enabled. > Redesign of the Ignite 3 component lifecycle is a part of this issue. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-19274) Sql. Jdbc side working with TIMESTAMP WITH LOCAL TIME ZONE did not take into account current tz while storing data.
[
https://issues.apache.org/jira/browse/IGNITE-19274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17716595#comment-17716595
]
Pavel Pereslegin edited comment on IGNITE-19274 at 4/26/23 8:31 AM:
The issue described in the task is one of the problems in terms of supporting
work with the client's timezone.
Currently we have the following types:
||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.Instant|yea|
*_WITH_LOCAL_TIME_ZONE types must take into account the client's local time
zone. Those. if the client is in the "GMT+3" time zone and is passing the value
"14:00", the value must be converted from GMT+3 to UTC and the value "11:00"
must be stored in the database.
Currently we do not take into account the client's/initiator's timezone in any
way.
h2. Proposal.
There are two implementation options, it all depends on when we will transfer
the client's time zone.
h2. 1. Transfer TimeZone from client per connection.
In this case the timezone from client will be stored per connection.
{code:java}
connect()
// save client's time zone to context/session
insert (time with local time zone '14:00')
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// transfer: value + timezone_offset
// returns: LocalTime
getTime()
// return value{code}
In this case all offsets will be applied on the server side, those
timestamp_with_time_zone we'll need to be LocalDateTime.
Since the timezone will only be set for each connection. Changing the client's
time zone during connection will have no effect.
E,g,
{code:java}
set timeZone='GMT+1'
connect()
insert (time with local time zone '14:00')
select time -> returns '14:00'
set timeZone='GMT+2'
select time -> returns '14:00'
{code}
h2. 2. Transfer TimeZone from client per query.
In this case, we will need to add some special type instead of LocalTime
because it does not store timezone information.
Since we will have time zone information on the client, we will simply
translate the value to the local ghb time zone when it is displayed.
Those. the scheme of work is approximately the following.
{code:java}
connect()
insert (time with local time zone '14:00')
// put client's timezone from the request to execution context.
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// returns: LocalTimeTz
getTime()
// if (value instanceof LocalTimeTz)
// read UTC '11:00' + local_timezone_offset{code}
But usually no one does this, the time zone is transmitted when connected to
the server.
And we need to separately discover how it will work with a Ignite thin client.
was (Author: xtern):
The issue described in the task is one of the problems in terms of supporting
work with the client's timezone.
Currently we have the following types:
||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.Instant|yea|
*_WITH_LOCAL_TIME_ZONE types must take into account the client's local time
zone. Those. if the client is in the "GMT+3" time zone and is passing the value
"14:00", the value must be converted from GMT+3 to UTC and the value "11:00"
must be stored in the database.
Currently we do not take into account the client's/initiator's timezone in any
way.
h2. Proposal.
There are two implementation options, it all depends on when we will transfer
the client's time zone.
h2. 1. Transfer TimeZone from client per connection.
In this case the timezone from client will be stored per connection.
{code:java}
connect()
// save client's time zone to context/session
insert (time with local time zone '14:00')
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// transfer: value + timezone_offset
// returns: LocalTime
getTime()
// return value{code}
In this case all offsets will be applied on the server side, those
timestamp_with_time_zone we'll need to be LocalDateTime.
Since the timezone will only be set for each connection. Changing the client's
time zone during connection will have no effect.
E,g,
{code:java}
set timeZone='GMT+1'
connect()
insert (time with local time zone '14:00')
select time -> returns '13:00'
set timeZone='GMT+2'
select time -> returns '13:00'
[jira] [Updated] (IGNITE-19365) Disable components until the cluster configuration is applied
[ https://issues.apache.org/jira/browse/IGNITE-19365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-19365: --- Description: There are instances where the Ignite 3 component requires to be "enabled" when the cluster configuration is applied. The lifecycle of the component can be adjusted to follow these steps: creating the component, starting the component, *waiting for the required cluster configuration, and enabling the component*. One particular example is the REST component, which needs to be configured with basic authentication. There is a time-lapse between cluster initialization and applying the authentication configuration. During this time, the REST API remains unauthenticated, and the cluster endpoints are available to everyone, as mentioned in the IGNITE-18943 ticket. The component needs to be started -> the cluster must be initialized -> but basic auth cluster configuration should be applied -> REST is enabled. Redesign of the Ignite 3 component lifecycle is a part of this issue. was: There are instances where the Ignite 3 component requires to be "enabled" when the cluster configuration is applied. The lifecycle of the component can be adjusted to follow these steps: creating the component, starting the component, *waiting for the required cluster configuration, and enabling the component*. One particular example is the REST component, which needs to be configured with basic authentication. There is a time-lapse between cluster initialization and applying the authentication configuration. During this time, the REST API remains unauthenticated, and the cluster endpoints are available to everyone, as mentioned in the IGNITE-18943 ticket. To address this issue, the component needs to be started, the cluster must be initialized, but basic auth configuration should not be applied until the cluster endpoints are authenticated, and finally, the basic authentication configuration should be applied, enabling the authentication to work properly. Redesign of the Ignite 3 component lifecycle is a part of this issue. > Disable components until the cluster configuration is applied > - > > Key: IGNITE-19365 > URL: https://issues.apache.org/jira/browse/IGNITE-19365 > Project: Ignite > Issue Type: New Feature > Components: clients, rest >Reporter: Vadim Pakhnushev >Priority: Major > Labels: ignite-3 > > There are instances where the Ignite 3 component requires to be "enabled" > when the cluster configuration is applied. The lifecycle of the component can > be adjusted to follow these steps: creating the component, starting the > component, *waiting for the required cluster configuration, and enabling the > component*. > One particular example is the REST component, which needs to be configured > with basic authentication. There is a time-lapse between cluster > initialization and applying the authentication configuration. During this > time, the REST API remains unauthenticated, and the cluster endpoints are > available to everyone, as mentioned in the IGNITE-18943 ticket. The component > needs to be started -> the cluster must be initialized -> but basic auth > cluster configuration should be applied -> REST is enabled. > Redesign of the Ignite 3 component lifecycle is a part of this issue. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19080) Save catalog changes to metastorage.
[ https://issues.apache.org/jira/browse/IGNITE-19080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov reassigned IGNITE-19080: - Assignee: Konstantin Orlov > Save catalog changes to metastorage. > > > Key: IGNITE-19080 > URL: https://issues.apache.org/jira/browse/IGNITE-19080 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Let's > * implement CatalogManager methods that will validate and save catalog > changes to the MetaStorage. > * implement Metastorage WatchListener that will apply these changes and > update CatalogService state. > Storing catalog snapshot may be ineffective as we may need to calculate a > diff between old and new catalog version for further event triggering > purpose. But we may save a while descriptors with some meta about the > operation. > Note: Let's make these changes aside to avoid breaking the current > implementation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-19274) Sql. Jdbc side working with TIMESTAMP WITH LOCAL TIME ZONE did not take into account current tz while storing data.
[
https://issues.apache.org/jira/browse/IGNITE-19274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17716595#comment-17716595
]
Pavel Pereslegin edited comment on IGNITE-19274 at 4/26/23 8:27 AM:
The issue described in the task is one of the problems in terms of supporting
work with the client's timezone.
Currently we have the following types:
||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.Instant|yea|
*_WITH_LOCAL_TIME_ZONE types must take into account the client's local time
zone. Those. if the client is in the "GMT+3" time zone and is passing the value
"14:00", the value must be converted from GMT+3 to UTC and the value "11:00"
must be stored in the database.
Currently we do not take into account the client's/initiator's timezone in any
way.
h2. Proposal.
There are two implementation options, it all depends on when we will transfer
the client's time zone.
h2. 1. Transfer TimeZone from client per connection.
In this case the timezone from client will be stored per connection.
{code:java}
connect()
// save client's time zone to context/session
insert (time with local time zone '14:00')
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// transfer: value + timezone_offset
// returns: LocalTime
getTime()
// return value{code}
In this case all offsets will be applied on the server side, those
timestamp_with_time_zone we'll need to be LocalDateTime.
Since the timezone will only be set for each connection. Changing the client's
time zone during connection will have no effect.
E,g,
{code:java}
set timeZone='GMT+1'
connect()
insert (time with local time zone '14:00')
select time -> returns '13:00'
set timeZone='GMT+2'
select time -> returns '13:00'
{code}
h2. 2. Transfer TimeZone from client per query.
In this case, we will need to add some special type instead of LocalTime
because it does not store timezone information.
Since we will have time zone information on the client, we will simply
translate the value to the local ghb time zone when it is displayed.
Those. the scheme of work is approximately the following.
{code:java}
connect()
insert (time with local time zone '14:00')
// put client's timezone from the request to execution context.
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// returns: LocalTimeTz
getTime()
// if (value instanceof LocalTimeTz)
// read UTC '11:00' + local_timezone_offset{code}
But usually no one does this, the time zone is transmitted when connected to
the server.
And we need to separately discover how it will work with a Ignite thin client.
was (Author: xtern):
The issue described in the task is one of the problems in terms of supporting
work with the client's timezone.
Currently we have the following types:
||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.Instant|yea|
*_WITH_LOCAL_TIME_ZONE types must take into account the client's local time
zone. Those. if the client is in the "GMT+3" time zone and is passing the value
"14:00", the value must be converted from GMT+3 to UTC and the value "11:00"
must be stored in the database.
Currently we do not take into account the client's/initiator's timezone in any
way.
h2. Proposal.
There are two implementation options, it all depends on when we will transfer
the client's time zone.
h2. 1. Transfer TimeZone from client per connection.
In this case the timezone from client will be stored per connection.
{code:java}
connect()
// save client's time zone to context/session
insert (time with local time zone '14:00')
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// transfer: value + timezone_offset
// returns: LocalTime
getTime()
// return value{code}
In this case all offsets will be applied on the server side, those
timestamp_with_time_zone we'll need to be LocalDateTime.
Since the timezone will only be set for each connection. Changing the client's
time zone during connection will have no effect.
E,g,
{code:java}
set timeZone='GMT+1'
connect()
insert (time with local time zone '14:00')
select time -> returns '13:00'
set timeZone='GMT+2'
select time -> returns '13:00'
[jira] [Comment Edited] (IGNITE-19274) Sql. Jdbc side working with TIMESTAMP WITH LOCAL TIME ZONE did not take into account current tz while storing data.
[
https://issues.apache.org/jira/browse/IGNITE-19274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17716595#comment-17716595
]
Pavel Pereslegin edited comment on IGNITE-19274 at 4/26/23 8:26 AM:
The issue described in the task is one of the problems in terms of supporting
work with the client's timezone.
Currently we have the following types:
||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.Instant|yea|
*_WITH_LOCAL_TIME_ZONE types must take into account the client's local time
zone. Those. if the client is in the "GMT+3" time zone and is passing the value
"14:00", the value must be converted from GMT+3 to UTC and the value "11:00"
must be stored in the database.
Currently we do not take into account the client's/initiator's timezone in any
way.
h2. Proposal.
There are two implementation options, it all depends on when we will transfer
the client's time zone.
h2. 1. Transfer TimeZone from client per connection.
In this case the timezone from client will be stored per connection.
{code:java}
connect()
// save client's time zone to context/session
insert (time with local time zone '14:00')
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// transfer: value + timezone_offset
// returns: LocalTime
getTime()
// return value{code}
In this case all offsets will be applied on the server side, those
timestamp_with_time_zone we'll need to be LocalDateTime.
Since the timezone will only be set for each connection. Changing the client's
time zone during connection will have no effect.
E,g,
{code:java}
set timeZone='GMT+1'
connect()
insert (time with local time zone '14:00')
select time -> returns '13:00'
set timeZone='GMT+2'
select time -> returns '13:00'
{code}
h2. 2. Transfer TimeZone from client per query.
In this case, we will need to add some special type instead of LocalTime
because it does not store timezone information.
Since we will have time zone information on the client, we will simply
translate the value to the local ghb time zone when it is displayed.
Those. the scheme of work is approximately the following.
{code:java}
connect()
insert (time with local time zone '14:00')
// put client's timezone from the request to execution context.
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// returns: LocalTimeTz
getTime()
// if (value instanceof LocalTimeTz)
// read UTC '11:00' + local_timezone_offset{code}
But usually no one does this, the time zone is transmitted when connected by
the server.
And we need to separately discover how it will work with a Ignite thin client.
was (Author: xtern):
The issue described in the task is one of the problems in terms of supporting
work with the client's timezone.
Currently we have the following types:
||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.Instant|yea|
*_WITH_LOCAL_TIME_ZONE types must take into account the client's local time
zone. Those. if the client is in the "GMT+3" time zone and is passing the value
"14:00", the value must be converted from GMT+3 to UTC and the value "11:00"
must be stored in the database.
Currently we do not take into account the client's/initiator's timezone in any
way.
h2. Proposal.
There are two implementation options, it all depends on when we will transfer
the client's time zone.
h2. 1. Transfer TimeZone from client per connection.
In this case the timezone from client will be stored per connection.
{code:java}
connect()
// store client's time zone
insert (time with local time zone '14:00')
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// transfer: value + timezone_offset
// returns: LocalTime
getTime()
// return value{code}
In this case all offsets will be applied on the server side, those
timestamp_with_time_zone we'll need to be LocalDateTime.
Since the timezone will only be set for each connection. Changing the client's
time zone during connection will have no effect.
E,g,
{code:java}
set timeZone='GMT+1'
connect()
insert (time with local time zone '14:00')
select time -> returns '13:00'
set timeZone='GMT+2'
select time -> returns '13:00'
{code}
h2. 2. Tran
[jira] [Updated] (IGNITE-19365) Disable components until the cluster configuration is applied
[ https://issues.apache.org/jira/browse/IGNITE-19365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-19365: --- Description: There are instances where the Ignite 3 component requires to be "enabled" when the cluster configuration is applied. The lifecycle of the component can be adjusted to follow these steps: creating the component, starting the component, *waiting for the required cluster configuration, and enabling the component*. One particular example is the REST component, which needs to be configured with basic authentication. There is a time-lapse between cluster initialization and applying the authentication configuration. During this time, the REST API remains unauthenticated, and the cluster endpoints are available to everyone, as mentioned in the IGNITE-18943 ticket. To address this issue, the component needs to be started, the cluster must be initialized, but basic auth configuration should not be applied until the cluster endpoints are authenticated, and finally, the basic authentication configuration should be applied, enabling the authentication to work properly. Redesign of the Ignite 3 component lifecycle is a part of this issue. was: There are the cases when the Ignite One example is basic authentication, where there is a time between cluster initialization and applying authentication config, in which REST API is not authenticated (IGNITE-18943). > Disable components until the cluster configuration is applied > - > > Key: IGNITE-19365 > URL: https://issues.apache.org/jira/browse/IGNITE-19365 > Project: Ignite > Issue Type: New Feature > Components: clients, rest >Reporter: Vadim Pakhnushev >Priority: Major > Labels: ignite-3 > > There are instances where the Ignite 3 component requires to be "enabled" > when the cluster configuration is applied. The lifecycle of the component can > be adjusted to follow these steps: creating the component, starting the > component, *waiting for the required cluster configuration, and enabling the > component*. > One particular example is the REST component, which needs to be configured > with basic authentication. There is a time-lapse between cluster > initialization and applying the authentication configuration. During this > time, the REST API remains unauthenticated, and the cluster endpoints are > available to everyone, as mentioned in the IGNITE-18943 ticket. To address > this issue, the component needs to be started, the cluster must be > initialized, but basic auth configuration should not be applied until the > cluster endpoints are authenticated, and finally, the basic authentication > configuration should be applied, enabling the authentication to work properly. > Redesign of the Ignite 3 component lifecycle is a part of this issue. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19274) Sql. Jdbc side working with TIMESTAMP WITH LOCAL TIME ZONE did not take into account current tz while storing data.
[
https://issues.apache.org/jira/browse/IGNITE-19274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-19274:
---
Labels: ignite-3 (was: )
> Sql. Jdbc side working with TIMESTAMP WITH LOCAL TIME ZONE did not take into
> account current tz while storing data.
> ---
>
> Key: IGNITE-19274
> URL: https://issues.apache.org/jira/browse/IGNITE-19274
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> The {{TIMESTAMP WITH LOCAL TIME ZONE}} data type is a variant of
> {{TIMESTAMP}} that includes a time zone offset in its value. Data stored in
> the database is normalized to the database time zone (UTC) and time zone
> offset is not stored as part of the column data. When the data is retrieved,
> it to be returned in the user's local session time zone.
> i.e:
> {noformat}
> CREATE TABLE timestamp(ts TIMESTAMP, t_tz TIMESTAMP WITH TIME ZONE);
> SET TIME ZONE 'tz1';
> INSERT INTO timestamp VALUES ('2011-01-01 01:01:01', TIMESTAMP WITH TIME ZONE
> '2011-01-01 01:01:01');
> SET TIME ZONE 'tz2';
> INSERT INTO timestamp VALUES ('2011-01-01 01:01:01', TIMESTAMP WITH TIME ZONE
> '2011-01-01 01:01:01');
> ...
> select * from timestamp;{noformat}
> returned rows need to be different in case of different tz1 and tz2 offsets
> but they are equals for now. Also returned representation need to be present
> in user session time zone.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-19367) Remove MvPartitionStorage#pollForVacuum
Ivan Bessonov created IGNITE-19367: -- Summary: Remove MvPartitionStorage#pollForVacuum Key: IGNITE-19367 URL: https://issues.apache.org/jira/browse/IGNITE-19367 Project: Ignite Issue Type: Improvement Reporter: Ivan Bessonov After https://issues.apache.org/jira/browse/IGNITE-19269, old method makes little sense and should be removed. Instead, we should implement proper bathing with try-locks and deadlock prevention. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-19274) Sql. Jdbc side working with TIMESTAMP WITH LOCAL TIME ZONE did not take into account current tz while storing data.
[
https://issues.apache.org/jira/browse/IGNITE-19274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17716595#comment-17716595
]
Pavel Pereslegin edited comment on IGNITE-19274 at 4/26/23 8:08 AM:
The issue described in the task is one of the problems in terms of supporting
work with the client's timezone.
Currently we have the following types:
||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.Instant|yea|
*_WITH_LOCAL_TIME_ZONE types must take into account the client's local time
zone. Those. if the client is in the "GMT+3" time zone and is passing the value
"14:00", the value must be converted from GMT+3 to UTC and the value "11:00"
must be stored in the database.
Currently we do not take into account the client's/initiator's timezone in any
way.
h2. Proposal.
There are two implementation options, it all depends on when we will transfer
the client's time zone.
h2. 1. Transfer TimeZone from client per connection.
In this case the timezone from client will be stored per connection.
{code:java}
connect()
// store client's time zone
insert (time with local time zone '14:00')
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// transfer: value + timezone_offset
// returns: LocalTime
getTime()
// return value{code}
In this case all offsets will be applied on the server side, those
timestamp_with_time_zone we'll need to be LocalDateTime.
Since the timezone will only be set for each connection. Changing the client's
time zone during connection will have no effect.
E,g,
{code:java}
set timeZone='GMT+1'
connect()
insert (time with local time zone '14:00')
select time -> returns '13:00'
set timeZone='GMT+2'
select time -> returns '13:00'
{code}
h2. 2. Transfer TimeZone from client per query.
In this case, we will need to add some special type instead of LocalTime
because it does not store timezone information.
Since we will have time zone information on the client, we will simply
translate the value to the local ghb time zone when it is displayed.
Those. the scheme of work is approximately the following.
{code:java}
connect()
insert (time with local time zone '14:00')
// put client's timezone from the request to execution context.
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// returns: LocalTimeTz
getTime()
// if (value instanceof LocalTimeTz)
// read UTC '11:00' + local_timezone_offset{code}
But usually no one does this, the time zone is transmitted when connected by
the server.
And we need to separately discover how it will work with a Ignite thin client.
was (Author: xtern):
The issue described in the task is one of the problems in terms of supporting
work with the client's timezone.
Currently we have the following types:
||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.Instant|yea|
{*}*_WITH_LOCAL_TIME_ZONE types must take into account the client's local time
zone{*}. Those. if the client is in the "GMT+3" time zone and is passing the
value "14:00", the value must be converted from GMT+3 to UTC and the value
"11:00" must be stored in the database.
Currently we do not take into account the client's/initiator's timezone in any
way.
h2. Proposal.
There are two implementation options, it all depends on when we will transfer
the client's time zone.
h2. 1. Transfer TimeZone from client per connection.
In this case the timezone from client will be stored per connection.
{code:java}
connect()
// store client's time zone
insert (time with local time zone '14:00')
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// transfer: value + timezone_offset
// returns: LocalTime
getTime()
// return value{code}
In this case all offsets will be applied on the server side, those
timestamp_with_time_zone we'll need to be LocalDateTime.
Since the timezone will only be set for each connection. Changing the client's
time zone during connection will have no effect.
E,g,
{code:java}
set timeZone='GMT+1'
connect()
insert (time with local time zone '14:00')
select time -> returns '13:00'
set timeZone='GMT+2'
select time -> returns '13:00'
{code}
h2. 2. Transfer TimeZ
[jira] [Comment Edited] (IGNITE-19274) Sql. Jdbc side working with TIMESTAMP WITH LOCAL TIME ZONE did not take into account current tz while storing data.
[
https://issues.apache.org/jira/browse/IGNITE-19274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17716595#comment-17716595
]
Pavel Pereslegin edited comment on IGNITE-19274 at 4/26/23 8:07 AM:
The issue described in the task is one of the problems in terms of supporting
work with the client's timezone.
Currently we have the following types:
||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.Instant|yea|
{*}*_WITH_LOCAL_TIME_ZONE types must take into account the client's local time
zone{*}. Those. if the client is in the "GMT+3" time zone and is passing the
value "14:00", the value must be converted from GMT+3 to UTC and the value
"11:00" must be stored in the database.
Currently we do not take into account the client's/initiator's timezone in any
way.
h2. Proposal.
There are two implementation options, it all depends on when we will transfer
the client's time zone.
h2. 1. Transfer TimeZone from client per connection.
In this case the timezone from client will be stored per connection.
{code:java}
connect()
// store client's time zone
insert (time with local time zone '14:00')
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// transfer: value + timezone_offset
// returns: LocalTime
getTime()
// return value{code}
In this case all offsets will be applied on the server side, those
timestamp_with_time_zone we'll need to be LocalDateTime.
Since the timezone will only be set for each connection. Changing the client's
time zone during connection will have no effect.
E,g,
{code:java}
set timeZone='GMT+1'
connect()
insert (time with local time zone '14:00')
select time -> returns '13:00'
set timeZone='GMT+2'
select time -> returns '13:00'
{code}
h2. 2. Transfer TimeZone from client per query.
In this case, we will need to add some special type instead of LocalTime
because it does not store timezone information.
Since we will have time zone information on the client, we will simply
translate the value to the local ghb time zone when it is displayed.
Those. the scheme of work is approximately the following.
{code:java}
connect()
insert (time with local time zone '14:00')
// put client's timezone from the request to execution context.
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// returns: LocalTimeTz
getTime()
// if (value instanceof LocalTimeTz)
// read UTC '11:00' + local_timezone_offset{code}
But usually no one does this, the time zone is transmitted when connected by
the server.
And we need to separately discover how it will work with a Ignite thin client.
was (Author: xtern):
The issue described in the task is one of the problems in terms of supporting
work with the client's timezone.
Currently we have the following types:
||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.Instant|yea|
*{*}_WITH_LOCAL_TIME_ZONE types must take into account the client's local time
zone.{*} Those. if the client is in the "GMT+3" time zone and is passing the
value "14:00", the value must be converted from GMT+3 to UTC and the value
"11:00" must be stored in the database.
Currently we do not take into account the client's/initiator's timezone in any
way.
h2. Proposal.
There are two implementation options, it all depends on when we will transfer
the client's time zone.
h2. 1. Transfer TimeZone from client per connection.
In this case the timezone from client will be stored per connection.
{code:java}
connect()
// store client's time zone
insert (time with local time zone '14:00')
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// transfer: value + timezone_offset
// returns: LocalTime
getTime()
// return value{code}
In this case all offsets will be applied on the server side, those
timestamp_with_time_zone we'll need to be LocalDateTime.
Since the timezone will only be set for each connection. Changing the client's
time zone during connection will have no effect.
E,g,
{code:java}
set timeZone='GMT+1'
connect()
insert (time with local time zone '14:00')
select time -> returns '13:00'
set timeZone='GMT+2'
select time -> returns '13:00'
{code}
h2. 2. Transf
[jira] [Comment Edited] (IGNITE-19274) Sql. Jdbc side working with TIMESTAMP WITH LOCAL TIME ZONE did not take into account current tz while storing data.
[
https://issues.apache.org/jira/browse/IGNITE-19274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17716595#comment-17716595
]
Pavel Pereslegin edited comment on IGNITE-19274 at 4/26/23 8:07 AM:
The issue described in the task is one of the problems in terms of supporting
work with the client's timezone.
Currently we have the following types:
||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.Instant|yea|
*{*}_WITH_LOCAL_TIME_ZONE types must take into account the client's local time
zone.{*} Those. if the client is in the "GMT+3" time zone and is passing the
value "14:00", the value must be converted from GMT+3 to UTC and the value
"11:00" must be stored in the database.
Currently we do not take into account the client's/initiator's timezone in any
way.
h2. Proposal.
There are two implementation options, it all depends on when we will transfer
the client's time zone.
h2. 1. Transfer TimeZone from client per connection.
In this case the timezone from client will be stored per connection.
{code:java}
connect()
// store client's time zone
insert (time with local time zone '14:00')
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// transfer: value + timezone_offset
// returns: LocalTime
getTime()
// return value{code}
In this case all offsets will be applied on the server side, those
timestamp_with_time_zone we'll need to be LocalDateTime.
Since the timezone will only be set for each connection. Changing the client's
time zone during connection will have no effect.
E,g,
{code:java}
set timeZone='GMT+1'
connect()
insert (time with local time zone '14:00')
select time -> returns '13:00'
set timeZone='GMT+2'
select time -> returns '13:00'
{code}
h2. 2. Transfer TimeZone from client per query.
In this case, we will need to add some special type instead of LocalTime
because it does not store timezone information.
Since we will have time zone information on the client, we will simply
translate the value to the local ghb time zone when it is displayed.
Those. the scheme of work is approximately the following.
{code:java}
connect()
insert (time with local time zone '14:00')
// put client's timezone from the request to execution context.
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// returns: LocalTimeTz
getTime()
// if (value instanceof LocalTimeTz)
// read UTC '11:00' + local_timezone_offset{code}
But usually no one does this, the time zone is transmitted when connected by
the server.
And we need to separately discover how it will work with a Ignite thin client.
was (Author: xtern):
The issue described in the task is one of the problems in terms of supporting
work with the client's timezone.
Currently we have the following types:
||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.Instant|yea|
**_WITH_LOCAL_TIME_ZONE types must take into account the client's local time
zone.* Those. if the client is in the "GMT+3" time zone and is passing the
value "14:00", the value must be converted from GMT+3 to UTC and the value
"11:00" must be stored in the database.
Currently we do not take into account the client's/initiator's timezone in any
way.
h2. Proposal.
There are two implementation options, it all depends on when we will transfer
the client's time zone.
h2. 1. Transfer TimeZone from client per connection.
In this case the timezone from client will be stored per connection.
{code:java}
connect()
// store client's time zone
insert (time with local time zone '14:00')
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// transfer: value + timezone_offset
// returns: LocalTime
getTime()
// return value{code}
In this case all offsets will be applied on the server side, those
timestamp_with_time_zone we'll need to be LocalDateTime.
Since the timezone will only be set for each connection. Changing the client's
time zone during connection will have no effect.
E,g,
{code:java}
set timeZone='GMT+1'
connect()
insert (time with local time zone '14:00')
select time -> returns '13:00'
set timeZone='GMT+2'
select time -> returns '13:00'
{code}
h2. 2
[jira] [Commented] (IGNITE-19274) Sql. Jdbc side working with TIMESTAMP WITH LOCAL TIME ZONE did not take into account current tz while storing data.
[
https://issues.apache.org/jira/browse/IGNITE-19274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17716595#comment-17716595
]
Pavel Pereslegin commented on IGNITE-19274:
---
The issue described in the task is one of the problems in terms of supporting
work with the client's timezone.
Currently we have the following types:
||Calcite type||JDBC Type||Current Ignite type||Type contains timezone info||
|TIME|java.sql.Time|java.time.LocalTime|no|
|TIME_WITH_LOCAL_TIME_ZONE|java.sql.Time|java.time.LocalTime|no|
|TIMESTAMP|java.sql.Timestamp|java.time.LocalDateTime|no|
|TIMESTAMP_WITH_LOCAL_TIME_ZONE|java.sql.Timestamp|java.time.Instant|yea|
**_WITH_LOCAL_TIME_ZONE types must take into account the client's local time
zone.* Those. if the client is in the "GMT+3" time zone and is passing the
value "14:00", the value must be converted from GMT+3 to UTC and the value
"11:00" must be stored in the database.
Currently we do not take into account the client's/initiator's timezone in any
way.
h2. Proposal.
There are two implementation options, it all depends on when we will transfer
the client's time zone.
h2. 1. Transfer TimeZone from client per connection.
In this case the timezone from client will be stored per connection.
{code:java}
connect()
// store client's time zone
insert (time with local time zone '14:00')
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// transfer: value + timezone_offset
// returns: LocalTime
getTime()
// return value{code}
In this case all offsets will be applied on the server side, those
timestamp_with_time_zone we'll need to be LocalDateTime.
Since the timezone will only be set for each connection. Changing the client's
time zone during connection will have no effect.
E,g,
{code:java}
set timeZone='GMT+1'
connect()
insert (time with local time zone '14:00')
select time -> returns '13:00'
set timeZone='GMT+2'
select time -> returns '13:00'
{code}
h2. 2. Transfer TimeZone from client per query.
In this case, we will need to add some special type instead of LocalTime
because it does not store timezone information.
Since we will have time zone information on the client, we will simply
translate the value to the local ghb time zone when it is displayed.
Those. the scheme of work is approximately the following.
{code:java}
connect()
insert (time with local time zone '14:00')
// put client's timezone from the request to execution context.
// store: value - timezone_offset = '11:00' (UTC)
select time with local time zone
// read: value from DB '11:00' UTC
// returns: LocalTimeTz
getTime()
// if (value instanceof LocalTimeTz)
// read UTC '11:00' + local_timezone_offset{code}
But usually no one does this, the time zone is transmitted when connected by
the server.
And we need to separately discover how it will work with a Ignite thin client.
> Sql. Jdbc side working with TIMESTAMP WITH LOCAL TIME ZONE did not take into
> account current tz while storing data.
> ---
>
> Key: IGNITE-19274
> URL: https://issues.apache.org/jira/browse/IGNITE-19274
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Assignee: Pavel Pereslegin
>Priority: Major
>
> The {{TIMESTAMP WITH LOCAL TIME ZONE}} data type is a variant of
> {{TIMESTAMP}} that includes a time zone offset in its value. Data stored in
> the database is normalized to the database time zone (UTC) and time zone
> offset is not stored as part of the column data. When the data is retrieved,
> it to be returned in the user's local session time zone.
> i.e:
> {noformat}
> CREATE TABLE timestamp(ts TIMESTAMP, t_tz TIMESTAMP WITH TIME ZONE);
> SET TIME ZONE 'tz1';
> INSERT INTO timestamp VALUES ('2011-01-01 01:01:01', TIMESTAMP WITH TIME ZONE
> '2011-01-01 01:01:01');
> SET TIME ZONE 'tz2';
> INSERT INTO timestamp VALUES ('2011-01-01 01:01:01', TIMESTAMP WITH TIME ZONE
> '2011-01-01 01:01:01');
> ...
> select * from timestamp;{noformat}
> returned rows need to be different in case of different tz1 and tz2 offsets
> but they are equals for now. Also returned representation need to be present
> in user session time zone.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19365) Disable components until the cluster configuration is applied
[ https://issues.apache.org/jira/browse/IGNITE-19365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-19365: --- Description: There are the cases when the Ignite One example is basic authentication, where there is a time between cluster initialization and applying authentication config, in which REST API is not authenticated (IGNITE-18943). was:One example is basic authentication, where there is a time between cluster initialization and applying authentication config, in which REST API is not authenticated (IGNITE-18943). > Disable components until the cluster configuration is applied > - > > Key: IGNITE-19365 > URL: https://issues.apache.org/jira/browse/IGNITE-19365 > Project: Ignite > Issue Type: New Feature > Components: clients, rest >Reporter: Vadim Pakhnushev >Priority: Major > Labels: ignite-3 > > There are the cases when the Ignite > One example is basic authentication, where there is a time between cluster > initialization and applying authentication config, in which REST API is not > authenticated (IGNITE-18943). -- This message was sent by Atlassian Jira (v8.20.10#820010)
