[jira] [Created] (IGNITE-8204) Tests hang with lazy query flag on
Alexander Paschenko created IGNITE-8204:
---
Summary: Tests hang with lazy query flag on
Key: IGNITE-8204
URL: https://issues.apache.org/jira/browse/IGNITE-8204
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Alexander Paschenko
Assignee: Alexander Paschenko
Fix For: 2.5
Affected tests:
{{IgniteCacheClientQueryReplicatedNodeRestartSelfTest.testRestart}}
{{IgniteCacheDistributedPartitionQueryNodeRestartsSelfTest.testJoinQueryUnstableTopology}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8050) Throw a meaningful exception when user issues TX SQL keyword with MVCC turned off
Alexander Paschenko created IGNITE-8050: --- Summary: Throw a meaningful exception when user issues TX SQL keyword with MVCC turned off Key: IGNITE-8050 URL: https://issues.apache.org/jira/browse/IGNITE-8050 Project: Ignite Issue Type: Task Reporter: Alexander Paschenko Fix For: 2.5 An exception must be thrown when the user issues TX SQL command (BEGIN, COMMIT, ROLLBACK) in absence of MVCC - ingoring these may be confusing and can lead to SQL engine behavior to behaving quite differently from what the user expects, esp. in terms of data consistency. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8016) Make sure checks in QueryUtils.typeForQueryEntity are sane
Alexander Paschenko created IGNITE-8016:
---
Summary: Make sure checks in QueryUtils.typeForQueryEntity are sane
Key: IGNITE-8016
URL: https://issues.apache.org/jira/browse/IGNITE-8016
Project: Ignite
Issue Type: Task
Components: cache, sql
Reporter: Alexander Paschenko
If one uses {{AffinityUuid}} (and thus, most likely, any {{AffinityKey}} at
all) as cache key in {{QueryEntity}} while not having an actual class for value
type, cache fails to start with error
{{Failed to find value class in the node classpath (use default marshaller to
enable binary objects)}}
Not only error message is misleading (as {{BinaryMarshaller}} is always on
now), the checks themselves must be verified for sanity as ruling them out
allowed to start cache, put data into it via cache API and perform SQL query
that worked.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-7956) MVCC TX: cache eviction operations for key-value API
Alexander Paschenko created IGNITE-7956: --- Summary: MVCC TX: cache eviction operations for key-value API Key: IGNITE-7956 URL: https://issues.apache.org/jira/browse/IGNITE-7956 Project: Ignite Issue Type: Task Components: cache Reporter: Alexander Paschenko Fix For: 2.5 We need to implement MVCC-compatible cache eviction operations for key-value API. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7955) MVCC TX: cache peek for key-value API
Alexander Paschenko created IGNITE-7955: --- Summary: MVCC TX: cache peek for key-value API Key: IGNITE-7955 URL: https://issues.apache.org/jira/browse/IGNITE-7955 Project: Ignite Issue Type: Task Components: cache Reporter: Alexander Paschenko Fix For: 2.5 We need to implement MVCC-compatible cache peek operation for key-value API. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7953) MVCC TX: continuous queries
Alexander Paschenko created IGNITE-7953: --- Summary: MVCC TX: continuous queries Key: IGNITE-7953 URL: https://issues.apache.org/jira/browse/IGNITE-7953 Project: Ignite Issue Type: Task Components: cache Reporter: Alexander Paschenko Fix For: 2.5 We need to implement MVCC-compatible continuous queries. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7952) MVCC TX: cache clear routines for key-value API
Alexander Paschenko created IGNITE-7952: --- Summary: MVCC TX: cache clear routines for key-value API Key: IGNITE-7952 URL: https://issues.apache.org/jira/browse/IGNITE-7952 Project: Ignite Issue Type: Task Components: cache Reporter: Alexander Paschenko Fix For: 2.5 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7942) Document streaming in thin JDBC driver
Alexander Paschenko created IGNITE-7942: --- Summary: Document streaming in thin JDBC driver Key: IGNITE-7942 URL: https://issues.apache.org/jira/browse/IGNITE-7942 Project: Ignite Issue Type: Task Components: documentation, jdbc, sql Reporter: Alexander Paschenko Fix For: 2.5 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7859) SQL streaming support via native API
Alexander Paschenko created IGNITE-7859:
---
Summary: SQL streaming support via native API
Key: IGNITE-7859
URL: https://issues.apache.org/jira/browse/IGNITE-7859
Project: Ignite
Issue Type: Task
Reporter: Alexander Paschenko
In addition to streaming via thin JDBC driver, ability to run same {{SET
STREAMING}} command should be added to cache API.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-7738) Allow 'multiple statements' in thin JDBC streaming mode
Alexander Paschenko created IGNITE-7738: --- Summary: Allow 'multiple statements' in thin JDBC streaming mode Key: IGNITE-7738 URL: https://issues.apache.org/jira/browse/IGNITE-7738 Project: Ignite Issue Type: Improvement Components: sql Reporter: Alexander Paschenko We need to update thin JDBC protocol to let user run multiple statements via Statement.execute(String) when connection is in streamed mode. Currently in streaming mode the server always receives all SQL in batches and its batch processing logic does not allow multiple statements altogether. If we're able to recognize initial nature of the statement, we'll be able to act appropriately, and for this to be possible additional information must be passed with each query in the batch. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7664) SQL: throw sane exception on unsupported SQL statements
Alexander Paschenko created IGNITE-7664: --- Summary: SQL: throw sane exception on unsupported SQL statements Key: IGNITE-7664 URL: https://issues.apache.org/jira/browse/IGNITE-7664 Project: Ignite Issue Type: Improvement Components: sql Reporter: Alexander Paschenko Assignee: Alexander Paschenko Fix For: 2.5 Inspired by this SO issue: [https://stackoverflow.com/questions/48708238/ignite-database-create-schema-assertionerror] We should handle unsupported stuff more gracefully both in core code and drivers. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7300) Allow expressions in SQL INSERTs within transactions
Alexander Paschenko created IGNITE-7300:
---
Summary: Allow expressions in SQL INSERTs within transactions
Key: IGNITE-7300
URL: https://issues.apache.org/jira/browse/IGNITE-7300
Project: Ignite
Issue Type: Bug
Environment: The problem is related to IGNITE-7267 - the latter honors
raw rows, but drops support for inserts with expressions which yield local
subqueries. To fix this, {{UpdatePlan.isLocalSubquery()}} must be honored.
Reporter: Alexander Paschenko
Assignee: Igor Seliverstov
Fix For: 2.4
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-7001) Refactor dynamic indexes test to use SQL API
Alexander Paschenko created IGNITE-7001: --- Summary: Refactor dynamic indexes test to use SQL API Key: IGNITE-7001 URL: https://issues.apache.org/jira/browse/IGNITE-7001 Project: Ignite Issue Type: Task Components: sql Reporter: Alexander Paschenko Assignee: Alexander Paschenko Fix For: 2.4 Tests for dynamic indexes should be refactored like those in IGNITE-6416 to use SQL API instead of relying on internal structures. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6996) Smarter handling of id fields in SQL values
Alexander Paschenko created IGNITE-6996:
---
Summary: Smarter handling of id fields in SQL values
Key: IGNITE-6996
URL: https://issues.apache.org/jira/browse/IGNITE-6996
Project: Ignite
Issue Type: Improvement
Components: sql
Reporter: Alexander Paschenko
Consider such case:
User wants to have a composite value (many value fields in {{QueryEntity}})
with one field associated with value's id (most likely matching cache key too).
Currently in order to insert such an object we will have to do something like
{{INSERT INTO Person(_key, id, name) values(1, 1, 'John')}}
And there's no way to avoid such a redundant repeat of the same value.
Suggested approach: I believe that we should specifically handle the case when
user specifies {{keyFieldName}} in configuration and specified field is field
of the value.
In such case, we could just do {{INSERT INTO Person(id, name) values(1,
'John')}} and derive {{_key}} value from {{id}} column. (And vice versa.)
At a glance, this also will require following tweaks:
- forbid performing SQL {{UPDATE}} on such column ({{id}} in above example);
- on an {{INSERT}}, check that {{_key}} and {{id}} values are the same, if both
specified.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-6950) Update documentation for user facing CREATE TABLE params
Alexander Paschenko created IGNITE-6950:
---
Summary: Update documentation for user facing CREATE TABLE params
Key: IGNITE-6950
URL: https://issues.apache.org/jira/browse/IGNITE-6950
Project: Ignite
Issue Type: Task
Security Level: Public (Viewable by anyone)
Components: documentation, sql
Affects Versions: 2.4
Reporter: Alexander Paschenko
Assignee: Alexander Paschenko
Fix For: 2.4
Changes to documentation should be made to reflect additional spelling for some
{{CREATE TABLE}} params added in IGNITE-6270.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-6637) No proper cleanup of statements cache is done on table drop
Alexander Paschenko created IGNITE-6637: --- Summary: No proper cleanup of statements cache is done on table drop Key: IGNITE-6637 URL: https://issues.apache.org/jira/browse/IGNITE-6637 Project: Ignite Issue Type: Bug Security Level: Public (Viewable by anyone) Components: sql Reporter: Alexander Paschenko Assignee: Alexander Paschenko We should cleanup statements cache whenever cache is deregistered - otherwise it's possible to retrieve from statements cache a statement that is prepared from H2 perspective but may not be executed. Reproducer attached. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6529) JDBC drivers don't provide correct metadata about columns' nullability
Alexander Paschenko created IGNITE-6529:
---
Summary: JDBC drivers don't provide correct metadata about
columns' nullability
Key: IGNITE-6529
URL: https://issues.apache.org/jira/browse/IGNITE-6529
Project: Ignite
Issue Type: Bug
Components: jdbc, sql
Reporter: Alexander Paschenko
For complete implementation of IGNITE-5648, we have to make JDBC drivers return
correct nullability flag for {{NOT NULL}} columns - currently corresponding
param of {{QueryField}} is ignored.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-6518) Smarter analysis of INSERT and MERGE statements at parsing stage
Alexander Paschenko created IGNITE-6518: --- Summary: Smarter analysis of INSERT and MERGE statements at parsing stage Key: IGNITE-6518 URL: https://issues.apache.org/jira/browse/IGNITE-6518 Project: Ignite Issue Type: Improvement Components: sql Reporter: Alexander Paschenko Fix For: 2.3 We could analyze INSERT and MERGE statements to detect that they don't specify data for key and/or value to notify users early that their query can't be executed within Ignite - prior to building plans and attempting to actually do anything. (Note how we check that CREATE TABLE doesn't declare columns for key - logic here would be similar.) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6270) Rename user facing CREATE TABLE param names to split words properly
Alexander Paschenko created IGNITE-6270:
---
Summary: Rename user facing CREATE TABLE param names to split
words properly
Key: IGNITE-6270
URL: https://issues.apache.org/jira/browse/IGNITE-6270
Project: Ignite
Issue Type: Improvement
Components: sql
Reporter: Alexander Paschenko
Fix For: 2.3
Currently, some {{CREATE TABLE}} params specified inside {{WITH}} clause look
like this: {{AFFINITYKEY}}, i.e. words are not separated by dashes as they
should be.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-6269) Document CREATE TABLE param for cache write sync mode on readme.io
Alexander Paschenko created IGNITE-6269: --- Summary: Document CREATE TABLE param for cache write sync mode on readme.io Key: IGNITE-6269 URL: https://issues.apache.org/jira/browse/IGNITE-6269 Project: Ignite Issue Type: Task Components: documentation, sql Reporter: Alexander Paschenko Fix For: 2.3 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-5837) Fix logic in DynamicIndexAbstractConcurrentSelfTest
Alexander Paschenko created IGNITE-5837: --- Summary: Fix logic in DynamicIndexAbstractConcurrentSelfTest Key: IGNITE-5837 URL: https://issues.apache.org/jira/browse/IGNITE-5837 Project: Ignite Issue Type: Test Reporter: Alexander Paschenko Assignee: Alexander Paschenko -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-5703) Add CREATE TABLE param for cache write sync mode
Alexander Paschenko created IGNITE-5703:
---
Summary: Add CREATE TABLE param for cache write sync mode
Key: IGNITE-5703
URL: https://issues.apache.org/jira/browse/IGNITE-5703
Project: Ignite
Issue Type: Task
Reporter: Alexander Paschenko
Assignee: Alexander Paschenko
Fix For: 2.1
Inspired by IGNITE-5702: instead of always enforcing {{FULL_SYNC}} mode, we
better give the user an opportunity to set it explicitly like we do with other
params (backups number, atomicity mode, etc.).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-5653) Add to query execution plan debug data for joins
Alexander Paschenko created IGNITE-5653: --- Summary: Add to query execution plan debug data for joins Key: IGNITE-5653 URL: https://issues.apache.org/jira/browse/IGNITE-5653 Project: Ignite Issue Type: Improvement Components: sql Affects Versions: 2.0 Environment: Plan should output table type (replicated/partitioned) and colocation information if possible. If we have this than we can warn (or throw exception) if users try to join non colocated tables with local joins. Reporter: Alexander Paschenko Fix For: 2.2 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-5652) Print slow query warnings on client node
Alexander Paschenko created IGNITE-5652: --- Summary: Print slow query warnings on client node Key: IGNITE-5652 URL: https://issues.apache.org/jira/browse/IGNITE-5652 Project: Ignite Issue Type: Improvement Components: sql Affects Versions: 2.0 Environment: Currently, only worker (MAP) nodes of the query print long query execution time warning to their console, for usability it would be nice to propagate this to the client node as well. Reporter: Alexander Paschenko Fix For: 2.2 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-5651) Add long query timeout property
Alexander Paschenko created IGNITE-5651: --- Summary: Add long query timeout property Key: IGNITE-5651 URL: https://issues.apache.org/jira/browse/IGNITE-5651 Project: Ignite Issue Type: Task Affects Versions: 2.0 Environment: It would be nice to allow users setting long execution timeout when sending a query - by doing so, user won't start getting dull long execution warnings which may be well expected. Instead, they will set their own acceptable timeout and will start seeing warnings only when they want to. Reporter: Alexander Paschenko Fix For: 2.2 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-5650) Add convenient API for getting column values
Alexander Paschenko created IGNITE-5650: --- Summary: Add convenient API for getting column values Key: IGNITE-5650 URL: https://issues.apache.org/jira/browse/IGNITE-5650 Project: Ignite Issue Type: Task Affects Versions: 2.0 Reporter: Alexander Paschenko Fix For: 2.2 It's desirable to have some API for getting column values from query results as current API operates only rows (raw Lists). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-5482) Implement basic caching of query results
Alexander Paschenko created IGNITE-5482: --- Summary: Implement basic caching of query results Key: IGNITE-5482 URL: https://issues.apache.org/jira/browse/IGNITE-5482 Project: Ignite Issue Type: Task Components: sql Affects Versions: 2.0 Reporter: Alexander Paschenko Assignee: Alexander Paschenko Fix For: 2.1 Sergi suggested that we reuse results of the same queries running simultaneously - i.e. if a query is being executed with the same arguments and flags again and again, there's no need to do actual querying of data, instead we can really run query once while other simultaneous runs will wait for those results. This strategy will be implemented on MAP stage of distributed query. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-5449) Add complex DDL+DML test.
Alexander Paschenko created IGNITE-5449: --- Summary: Add complex DDL+DML test. Key: IGNITE-5449 URL: https://issues.apache.org/jira/browse/IGNITE-5449 Project: Ignite Issue Type: Task Components: sql Reporter: Alexander Paschenko Assignee: Alexander Paschenko Fix For: 2.1 We need a test that will test data flow behavior in chain of DML+DDL operations as a whole. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (IGNITE-5291) SQL: plans cache does not clear on cache stop
Alexander Paschenko created IGNITE-5291:
---
Summary: SQL: plans cache does not clear on cache stop
Key: IGNITE-5291
URL: https://issues.apache.org/jira/browse/IGNITE-5291
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 2.0
Environment: After cache-schema decoupling mutation of
{{DmlStatementsProcessor#planCache}} appears to be broken (different pieces of
code contexts operate different schema names), have to do this consistently.
Reporter: Alexander Paschenko
Assignee: Alexander Paschenko
Fix For: 2.1
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (IGNITE-5289) SQL: forbid WITH queries
Alexander Paschenko created IGNITE-5289: --- Summary: SQL: forbid WITH queries Key: IGNITE-5289 URL: https://issues.apache.org/jira/browse/IGNITE-5289 Project: Ignite Issue Type: Task Components: sql Reporter: Alexander Paschenko Assignee: Alexander Paschenko Recursive queries starting with WITH keyword must be explicitly forbidden. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (IGNITE-5116) Handle cache destroy in DmlStatementsProcessor
Alexander Paschenko created IGNITE-5116: --- Summary: Handle cache destroy in DmlStatementsProcessor Key: IGNITE-5116 URL: https://issues.apache.org/jira/browse/IGNITE-5116 Project: Ignite Issue Type: Bug Components: SQL Affects Versions: 1.9 Reporter: Alexander Paschenko Assignee: Alexander Paschenko Fix For: 2.1 We have to clear plans cache for Ignite cache that is being destroyed as otherwise cache context leaks with obsolete DML execution plans -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (IGNITE-4998) Add more dynamic indexing tests for various cache modes
Alexander Paschenko created IGNITE-4998: --- Summary: Add more dynamic indexing tests for various cache modes Key: IGNITE-4998 URL: https://issues.apache.org/jira/browse/IGNITE-4998 Project: Ignite Issue Type: Sub-task Reporter: Alexander Paschenko Assignee: Alexander Paschenko Fix For: 2.0 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (IGNITE-4953) Rework logic of concurrent schema changes
Alexander Paschenko created IGNITE-4953: --- Summary: Rework logic of concurrent schema changes Key: IGNITE-4953 URL: https://issues.apache.org/jira/browse/IGNITE-4953 Project: Ignite Issue Type: Bug Components: SQL Affects Versions: 2.0 Reporter: Alexander Paschenko Assignee: Alexander Paschenko Fix For: 2.0 H2's prepared statements store references to indexes that were present when the statement was parsed and initialized - this means that currently there's no way to prevent index usage if it goes down between the moment when the statement is created and actually executed. Have to come up with some new locking schema. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (IGNITE-4947) Create AI 2.0 TC suites
Alexander Paschenko created IGNITE-4947: --- Summary: Create AI 2.0 TC suites Key: IGNITE-4947 URL: https://issues.apache.org/jira/browse/IGNITE-4947 Project: Ignite Issue Type: Task Affects Versions: 2.0 Reporter: Alexander Paschenko Assignee: Alexander Paschenko Fix For: 2.0 Due to OptimizedMarshaller removal from public API per IGNITE-4938, we need all-new post-OptimizedMarshaller set of TC suites that will be used by default after 2.0 is released. What has to be done: - Remove all OptimizedMarshaller specific suites - Make all 'binary' suites 'standard' -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (IGNITE-4905) ClassCastException in DML benchmarks
Alexander Paschenko created IGNITE-4905: --- Summary: ClassCastException in DML benchmarks Key: IGNITE-4905 URL: https://issues.apache.org/jira/browse/IGNITE-4905 Project: Ignite Issue Type: Bug Components: SQL Affects Versions: 1.9 Reporter: Alexander Paschenko Assignee: Alexander Paschenko Fix For: 2.0 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (IGNITE-4903) More SQL side tests for CREATE/DROP INDEX
Alexander Paschenko created IGNITE-4903: --- Summary: More SQL side tests for CREATE/DROP INDEX Key: IGNITE-4903 URL: https://issues.apache.org/jira/browse/IGNITE-4903 Project: Ignite Issue Type: Sub-task Components: SQL Reporter: Alexander Paschenko Assignee: Alexander Paschenko Fix For: 2.0 IGNITE-4656 needs more tests to check indexes' actual usage and correctness. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (IGNITE-4742) Flaky IgniteCacheUpdateSqlQuerySelfTest.testTypeConversions
Alexander Paschenko created IGNITE-4742: --- Summary: Flaky IgniteCacheUpdateSqlQuerySelfTest.testTypeConversions Key: IGNITE-4742 URL: https://issues.apache.org/jira/browse/IGNITE-4742 Project: Ignite Issue Type: Bug Components: SQL Affects Versions: 1.8 Reporter: Alexander Paschenko Assignee: Alexander Paschenko Priority: Minor Fix For: 1.9 This test fails randomly on various query related suites and very seldom locally. Seems to be test problem and not of what is tested. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (IGNITE-4732) Invalid ids quoting logic in DML and GridSqlFunction
Alexander Paschenko created IGNITE-4732: --- Summary: Invalid ids quoting logic in DML and GridSqlFunction Key: IGNITE-4732 URL: https://issues.apache.org/jira/browse/IGNITE-4732 Project: Ignite Issue Type: Bug Components: SQL Affects Versions: 1.9 Reporter: Alexander Paschenko Assignee: Alexander Paschenko Fix For: 1.9 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (IGNITE-4660) Add DML capabilities to legacy JDBC driver
Alexander Paschenko created IGNITE-4660: --- Summary: Add DML capabilities to legacy JDBC driver Key: IGNITE-4660 URL: https://issues.apache.org/jira/browse/IGNITE-4660 Project: Ignite Issue Type: Improvement Components: jdbc-driver, SQL Reporter: Alexander Paschenko Assignee: Alexander Paschenko Fix For: 2.0 Legacy Ignite JDBC driver lacks DML capabilities, but it turns out that there still are plenty of its users who need DML too, so we should de-deprecate it and enable updating operations in it. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (IGNITE-4575) Implement in Ignite wrapper for enums based on H2 user value type
Alexander Paschenko created IGNITE-4575: --- Summary: Implement in Ignite wrapper for enums based on H2 user value type Key: IGNITE-4575 URL: https://issues.apache.org/jira/browse/IGNITE-4575 Project: Ignite Issue Type: Sub-task Components: SQL Reporter: Alexander Paschenko Assignee: Alexander Paschenko Fix For: 1.9 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-4574) Introduce user value types to H2 w/custom conversion logic
Alexander Paschenko created IGNITE-4574: --- Summary: Introduce user value types to H2 w/custom conversion logic Key: IGNITE-4574 URL: https://issues.apache.org/jira/browse/IGNITE-4574 Project: Ignite Issue Type: Sub-task Reporter: Alexander Paschenko -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-4573) Optimize H2 comparisons w/constant
Alexander Paschenko created IGNITE-4573:
---
Summary: Optimize H2 comparisons w/constant
Key: IGNITE-4573
URL: https://issues.apache.org/jira/browse/IGNITE-4573
Project: Ignite
Issue Type: Sub-task
Components: SQL
Reporter: Alexander Paschenko
Assignee: Alexander Paschenko
Currently H2 performs constant conversions for each row - say, for {{WHERE
person.id = '1'}} the {{'1'}} will be converted to {{int}} for each row which
is clearly redundant.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-4570) Handle CREATE INDEX statements
Alexander Paschenko created IGNITE-4570: --- Summary: Handle CREATE INDEX statements Key: IGNITE-4570 URL: https://issues.apache.org/jira/browse/IGNITE-4570 Project: Ignite Issue Type: Sub-task Components: SQL Reporter: Alexander Paschenko Assignee: Alexander Paschenko Fix For: 1.9 Parse and execute CREATE INDEX boiling down to IgniteCacheEx.createQueryIndex introduced by IGNITE-4566 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-4569) Create local portion of index w/table locking
Alexander Paschenko created IGNITE-4569: --- Summary: Create local portion of index w/table locking Key: IGNITE-4569 URL: https://issues.apache.org/jira/browse/IGNITE-4569 Project: Ignite Issue Type: Sub-task Components: cache, SQL Reporter: Alexander Paschenko Assignee: Alexander Paschenko Fix For: 1.9 Actual index data modification - initially will render whole SQL table inaccessible during initial index buildup -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-4568) Dynamically create distributed index
Alexander Paschenko created IGNITE-4568: --- Summary: Dynamically create distributed index Key: IGNITE-4568 URL: https://issues.apache.org/jira/browse/IGNITE-4568 Project: Ignite Issue Type: Sub-task Components: messaging, SQL Reporter: Alexander Paschenko Assignee: Alexander Paschenko Fix For: 1.9 Handle index creation messaging using means introduced by IGNITE-4567 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-4567) Design and implement means for distributed DDL statements
Alexander Paschenko created IGNITE-4567: --- Summary: Design and implement means for distributed DDL statements Key: IGNITE-4567 URL: https://issues.apache.org/jira/browse/IGNITE-4567 Project: Ignite Issue Type: Sub-task Components: messaging, SQL Reporter: Alexander Paschenko Assignee: Alexander Paschenko We need some kind of common way to handle stuff like CREATE INDEX/CREATE TABLE statements - in other words, run potentially long-running (and possibly cache locking) DDL operations on cluster nodes that would allow using new tables/indexes only when all nodes have performed requested operations and data modifications. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-4566) Introduce IgniteCacheEx.createQueryIndex
Alexander Paschenko created IGNITE-4566: --- Summary: Introduce IgniteCacheEx.createQueryIndex Key: IGNITE-4566 URL: https://issues.apache.org/jira/browse/IGNITE-4566 Project: Ignite Issue Type: Sub-task Components: cache, SQL Reporter: Alexander Paschenko Assignee: Alexander Paschenko Fix For: 1.9 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-4565) Support CREATE INDEX DDL statements
Alexander Paschenko created IGNITE-4565: --- Summary: Support CREATE INDEX DDL statements Key: IGNITE-4565 URL: https://issues.apache.org/jira/browse/IGNITE-4565 Project: Ignite Issue Type: New Feature Components: SQL Reporter: Alexander Paschenko Assignee: Alexander Paschenko Fix For: 1.9 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-4553) Parse CREATE INDEX statements
Alexander Paschenko created IGNITE-4553: --- Summary: Parse CREATE INDEX statements Key: IGNITE-4553 URL: https://issues.apache.org/jira/browse/IGNITE-4553 Project: Ignite Issue Type: Task Components: SQL Reporter: Alexander Paschenko Assignee: Alexander Paschenko Fix For: 1.9 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-4490) Optimize DML for fast INSERT and MERGE
Alexander Paschenko created IGNITE-4490: --- Summary: Optimize DML for fast INSERT and MERGE Key: IGNITE-4490 URL: https://issues.apache.org/jira/browse/IGNITE-4490 Project: Ignite Issue Type: Improvement Components: SQL Affects Versions: 1.8 Reporter: Alexander Paschenko Assignee: Alexander Paschenko Fix For: 1.8 It's possible to avoid any SQL querying and map some INSERT and MERGE statements to cache operations in a way similar to that of UPDATE and DELETE - i.e. don't make queries when there are no expressions to evaluate in the query and enhance update plans to perform direct cache operations when INSERT and MERGE affect columns _key and _value only. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-4489) Maintain correct MERGE semantic in DML
Alexander Paschenko created IGNITE-4489: --- Summary: Maintain correct MERGE semantic in DML Key: IGNITE-4489 URL: https://issues.apache.org/jira/browse/IGNITE-4489 Project: Ignite Issue Type: Bug Components: SQL Affects Versions: 1.8 Reporter: Alexander Paschenko Assignee: Alexander Paschenko Fix For: 1.8 Currently it's impossible to MERGE object in UPDATE style - i.e. when key is present in cache, unaffected field values should be retained, and instead of building new object we should base it on previous one for given key. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-4486) Add serialVersionUID to AttributeNodeFilter
Alexander Paschenko created IGNITE-4486: --- Summary: Add serialVersionUID to AttributeNodeFilter Key: IGNITE-4486 URL: https://issues.apache.org/jira/browse/IGNITE-4486 Project: Ignite Issue Type: Bug Components: general Affects Versions: 1.8 Reporter: Alexander Paschenko Assignee: Alexander Paschenko Fix For: 1.8 Subj. - in particular, without it, TC build fails all at once -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-4383) Update section on binary marshaller in Apache Ignite Readme.io docs
Alexander Paschenko created IGNITE-4383: --- Summary: Update section on binary marshaller in Apache Ignite Readme.io docs Key: IGNITE-4383 URL: https://issues.apache.org/jira/browse/IGNITE-4383 Project: Ignite Issue Type: Task Components: binary, documentation Reporter: Alexander Paschenko Assignee: Alexander Paschenko Fix For: 1.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-4363) Inner properties mutation broken in DML
Alexander Paschenko created IGNITE-4363: --- Summary: Inner properties mutation broken in DML Key: IGNITE-4363 URL: https://issues.apache.org/jira/browse/IGNITE-4363 Project: Ignite Issue Type: Bug Components: binary, SQL Affects Versions: 1.8 Reporter: Alexander Paschenko Assignee: Alexander Paschenko Fix For: 1.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-4343) Check mutable entries for existence properly inside DML entry processors
Alexander Paschenko created IGNITE-4343: --- Summary: Check mutable entries for existence properly inside DML entry processors Key: IGNITE-4343 URL: https://issues.apache.org/jira/browse/IGNITE-4343 Project: Ignite Issue Type: Improvement Components: SQL Affects Versions: 1.8 Reporter: Alexander Paschenko Assignee: Alexander Paschenko Fix For: 1.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-4340) Implicitly cast new column values to expected types on SQL UPDATE
Alexander Paschenko created IGNITE-4340:
---
Summary: Implicitly cast new column values to expected types on
SQL UPDATE
Key: IGNITE-4340
URL: https://issues.apache.org/jira/browse/IGNITE-4340
Project: Ignite
Issue Type: Improvement
Components: SQL
Affects Versions: 1.8
Reporter: Alexander Paschenko
Assignee: Alexander Paschenko
Fix For: 1.8
When the following query is run,
{code:sql}
update AllTypes set longCol = 1 where _key = ?
{code}
it fails with exception
{noformat}
Suppressed: java.lang.ClassCastException: java.lang.Integer cannot be cast to
java.lang.Long
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$RowDescriptor.wrap(IgniteH2Indexing.java:2960)
at
org.apache.ignite.internal.processors.query.h2.opt.GridH2AbstractKeyValueRow.getValue(GridH2AbstractKeyValueRow.java:316)
at
org.h2.index.BaseIndex.compareRows(BaseIndex.java:294)
at
org.apache.ignite.internal.processors.query.h2.opt.GridH2TreeIndex$2.compare(GridH2TreeIndex.java:103)
at
org.apache.ignite.internal.processors.query.h2.opt.GridH2TreeIndex$2.compare(GridH2TreeIndex.java:95)
at
java.util.concurrent.ConcurrentSkipListMap$ComparableUsingComparator.compareTo(ConcurrentSkipListMap.java:647)
at
java.util.concurrent.ConcurrentSkipListMap.findPredecessor(ConcurrentSkipListMap.java:727)
at
java.util.concurrent.ConcurrentSkipListMap.doPut(ConcurrentSkipListMap.java:850)
at
java.util.concurrent.ConcurrentSkipListMap.put(ConcurrentSkipListMap.java:1645)
at
org.apache.ignite.internal.processors.query.h2.opt.GridH2TreeIndex.put(GridH2TreeIndex.java:362)
at
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.doUpdate(GridH2Table.java:566)
at
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:495)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:603)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:737)
at
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:431)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.updateIndex(GridCacheMapEntry.java:4019)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2458)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2385)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1787)
{noformat}
It's due to that UPDATE's SELECT part selects 1 as int, and that's what we're
setting to field. Problem can be solved by casting SELECTed values to the types
that columns expect.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-4338) Cross-schema SQL SELECT on partitioned cache fails for no good reason
Alexander Paschenko created IGNITE-4338: --- Summary: Cross-schema SQL SELECT on partitioned cache fails for no good reason Key: IGNITE-4338 URL: https://issues.apache.org/jira/browse/IGNITE-4338 Project: Ignite Issue Type: Bug Components: SQL Affects Versions: 1.8 Reporter: Alexander Paschenko Fix For: 2.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-4333) SQL engine does not preserve metadata about array content's type
Alexander Paschenko created IGNITE-4333:
---
Summary: SQL engine does not preserve metadata about array
content's type
Key: IGNITE-4333
URL: https://issues.apache.org/jira/browse/IGNITE-4333
Project: Ignite
Issue Type: Sub-task
Components: SQL
Affects Versions: 1.8
Reporter: Alexander Paschenko
Fix For: 2.0
This problem arises on SQL *SELECT* from grid table and on results page
transfer over network.
First, when data is *SELECT* ed,
{{org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.RowDescriptor#wrap}}
does not look at array's component type and tries to convert any array to
{{Object[]}} which turns to {{ClassCastException}} when array is of primitive
type and erases metadata about its contents when its type is not primitive.
Then, when results page is transferred over network, array is wrapped into
{{org.apache.ignite.internal.processors.query.h2.twostep.msg.GridH2Array}}
which does not have any metadata too, so, even if we had returned primitive
array from native H2's local *SELECT*, information about its primitiveness
would be lost anyway, and it would be converted to, say, {{java.lang.Byte[]}}
after all.
So, currently there's no way to *SELECT* a primitive array field via SQL.
Probably this could be fixed by changing {{GridH2Array}}, but this would break
backward compatibility, so it's an open question for now.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-4331) Binary marshaller does not preserve component type when deserealizing even basic array typed fields
Alexander Paschenko created IGNITE-4331:
---
Summary: Binary marshaller does not preserve component type when
deserealizing even basic array typed fields
Key: IGNITE-4331
URL: https://issues.apache.org/jira/browse/IGNITE-4331
Project: Ignite
Issue Type: Sub-task
Components: binary
Affects Versions: 1.8
Reporter: Alexander Paschenko
Fix For: 2.0
How to reproduce: try to deserialize *single* field having type of {{Byte[]}}
or any other primitive wrapper type array. It will be deserialized as
{{Object[]}} and won't be suitable even to set the same field's value again -
metadata check on object building will fail as required ({{Byte[]}}) and given
({{Object[]}}) types won't match.
As agreed with [~vozerov], currently we're not fixing it. Probably will get
back to this while working on 2.0 release.
Discovered by [~skozlov] while running SQL DML examples during 1.8 release QA
process, exact reasons found by [~al.psc].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-4327) Failed to INSERT array of Bytes from SELECT
Alexander Paschenko created IGNITE-4327:
---
Summary: Failed to INSERT array of Bytes from SELECT
Key: IGNITE-4327
URL: https://issues.apache.org/jira/browse/IGNITE-4327
Project: Ignite
Issue Type: Bug
Components: binary, SQL
Affects Versions: 1.8
Reporter: Alexander Paschenko
Fix For: 2.0
An attempt to INSERT binary object having a {{Byte[]}} typed field from
{{SELECT *}} yeilds following exception (initially observed in IGNITE-4323):
{code}
Exception in thread "main" javax.cache.CacheException: class
org.apache.ignite.IgniteCheckedException: Can not set [Ljava.lang.Byte; field
org.apache.ignite.testtools.model.AllTypes.bytesCol to [Ljava.lang.Object;
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1440)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.cacheException(IgniteCacheProxy.java:2183)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.get(IgniteCacheProxy.java:1125)
at
org.apache.ignite.examples.datagrid.ExtSqlExample.main(ExtSqlExample.java:237)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
Caused by: class org.apache.ignite.IgniteCheckedException: Can not set
[Ljava.lang.Byte; field org.apache.ignite.testtools.model.AllTypes.bytesCol to
[Ljava.lang.Object;
at
org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7185)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:169)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:118)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.get(GridDhtAtomicCache.java:482)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4783)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1395)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.get(IgniteCacheProxy.java:1118)
... 6 more
Caused by: java.lang.IllegalArgumentException: Can not set [Ljava.lang.Byte;
field org.apache.ignite.testtools.model.AllTypes.bytesCol to [Ljava.lang.Object;
at
sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:164)
at
sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:168)
at
sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:81)
at java.lang.reflect.Field.set(Field.java:741)
at
org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read(BinaryFieldAccessor.java:643)
at
org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:829)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1498)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1450)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:637)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:142)
at
org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinary(CacheObjectContext.java:272)
at
org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:160)
at
org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:147)
at
org.apache.ignite.internal.processors.cache.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1760)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.setResult(GridPartitionedSingleGetFuture.java:630)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.onResult(GridPartitionedSingleGetFuture.java:492)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.processNearSingleGetResponse(GridDhtCacheAdapter.java:155)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$2200(GridDhtAtomicCache.java:125)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$12.apply(GridDhtAtomicCache.java:440)
at
[jira] [Created] (IGNITE-4320) Minor fixes in DmlStatementsProcessor
Alexander Paschenko created IGNITE-4320: --- Summary: Minor fixes in DmlStatementsProcessor Key: IGNITE-4320 URL: https://issues.apache.org/jira/browse/IGNITE-4320 Project: Ignite Issue Type: Improvement Affects Versions: 1.8 Reporter: Alexander Paschenko Assignee: Alexander Paschenko 1. Important local variable renamed to more sane name 2. Removed duplicate operation manipulations in doUpdate 3. Small optimization in doUpdate (don't read key fields as we won't use them anyway) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-4319) Fix IgniteCacheAbstractSqlDmlQuerySelfTest
Alexander Paschenko created IGNITE-4319: --- Summary: Fix IgniteCacheAbstractSqlDmlQuerySelfTest Key: IGNITE-4319 URL: https://issues.apache.org/jira/browse/IGNITE-4319 Project: Ignite Issue Type: Test Reporter: Alexander Paschenko Somehow it's green on TC in non binary mode but fails locally. Purely test problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-4308) Make QueryEntity.keyFields optional for caches having SQL types as keys
Alexander Paschenko created IGNITE-4308: --- Summary: Make QueryEntity.keyFields optional for caches having SQL types as keys Key: IGNITE-4308 URL: https://issues.apache.org/jira/browse/IGNITE-4308 Project: Ignite Issue Type: Improvement Components: SQL Affects Versions: 1.8 Reporter: Alexander Paschenko Assignee: Alexander Paschenko Initial implementation of DML requires the user to specify keyFields in configuration explicitly, even if it's empty, in cases when DML is used and binary marshaller is used. As [~vozerov] noted, it could affect usability, if even a little, so this should be fixed - when a primitive/simple SQL type is used as a key, it's obvious that there's no key fields and hence it's not necessary to specify empty keyFields in this case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-4280) Fix failing tests in IgniteBinaryCacheQueryTestSuite
Alexander Paschenko created IGNITE-4280: --- Summary: Fix failing tests in IgniteBinaryCacheQueryTestSuite Key: IGNITE-4280 URL: https://issues.apache.org/jira/browse/IGNITE-4280 Project: Ignite Issue Type: Test Reporter: Alexander Paschenko Assignee: Alexander Paschenko Fix For: 1.8 Details: https://issues.apache.org/jira/browse/IGNITE-2294?focusedCommentId=15683377 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-4279) Make DML related JDBC driver tests pass within suite
Alexander Paschenko created IGNITE-4279: --- Summary: Make DML related JDBC driver tests pass within suite Key: IGNITE-4279 URL: https://issues.apache.org/jira/browse/IGNITE-4279 Project: Ignite Issue Type: Test Reporter: Alexander Paschenko Assignee: Alexander Paschenko Fix For: 1.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-4269) Implement query rewriting in JDBC driver for batch statements
Alexander Paschenko created IGNITE-4269: --- Summary: Implement query rewriting in JDBC driver for batch statements Key: IGNITE-4269 URL: https://issues.apache.org/jira/browse/IGNITE-4269 Project: Ignite Issue Type: New Feature Reporter: Alexander Paschenko Assignee: Alexander Paschenko In the course of review of initial DML implementation, it has been agreed that the first attempt to implement batching (via series of individual queries) is rather incorrect (effectively series of individual queries instead of one larger query). So it's been decided not to include batching into initial release and rather implement it the right way shortly in nearest releases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-4224) Resolve JdbcQueryTask compatibility issues
Alexander Paschenko created IGNITE-4224: --- Summary: Resolve JdbcQueryTask compatibility issues Key: IGNITE-4224 URL: https://issues.apache.org/jira/browse/IGNITE-4224 Project: Ignite Issue Type: Sub-task Reporter: Alexander Paschenko Assignee: Alexander Paschenko Suggested solution is to move disturbing changes into separate class while making old one deprecated and destined for deletion in Ignite 2.0, and send new kind of tasks to compatible nodes only (having version 1.8.0 or newer). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-4197) Rework UPDATE and DELETE in more streaming friendly manner
Alexander Paschenko created IGNITE-4197:
---
Summary: Rework UPDATE and DELETE in more streaming friendly manner
Key: IGNITE-4197
URL: https://issues.apache.org/jira/browse/IGNITE-4197
Project: Ignite
Issue Type: Sub-task
Reporter: Alexander Paschenko
Assignee: Alexander Paschenko
Limit size of batch in UPDATE/DELETE ("paginate" them). Based on review
comments from Sergey V.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-4168) Cross-schema DML queries do not work
Alexander Paschenko created IGNITE-4168: --- Summary: Cross-schema DML queries do not work Key: IGNITE-4168 URL: https://issues.apache.org/jira/browse/IGNITE-4168 Project: Ignite Issue Type: Bug Components: SQL Reporter: Alexander Paschenko Assignee: Alexander Paschenko Fix For: 1.8 When a DML query has schema (i.e. cache name) specified, it is ignored and cache operations get carried out against the cache the 'query' method was called upon which clearly is not right. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-4011) Automatically compute hash codes for newly built binary objects
Alexander Paschenko created IGNITE-4011: --- Summary: Automatically compute hash codes for newly built binary objects Key: IGNITE-4011 URL: https://issues.apache.org/jira/browse/IGNITE-4011 Project: Ignite Issue Type: Task Components: binary, cache Reporter: Alexander Paschenko Assignee: Alexander Paschenko Fix For: 1.8 For binary keys built automatically inside SQL engine during INSERT or MERGE, we need to compute hash codes automatically because in this case the user does not interact with any builders and can't set hash code explicitly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3919) Let JDBC driver have H2's metadata for PreparedStatements
Alexander Paschenko created IGNITE-3919: --- Summary: Let JDBC driver have H2's metadata for PreparedStatements Key: IGNITE-3919 URL: https://issues.apache.org/jira/browse/IGNITE-3919 Project: Ignite Issue Type: Task Components: jdbc-driver Affects Versions: 1.8 Reporter: Alexander Paschenko Assignee: Alexander Paschenko Fix For: 2.0 Subj. - needed for IGNITE-3910. Will do it in DML branch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3830) Introduce benchmarks for DML operations
Alexander Paschenko created IGNITE-3830: --- Summary: Introduce benchmarks for DML operations Key: IGNITE-3830 URL: https://issues.apache.org/jira/browse/IGNITE-3830 Project: Ignite Issue Type: Task Components: SQL, yardstick Reporter: Alexander Paschenko Assignee: Alexander Paschenko -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3633) Throw an exception when an object without explicitly set hash code
Alexander Paschenko created IGNITE-3633: --- Summary: Throw an exception when an object without explicitly set hash code Key: IGNITE-3633 URL: https://issues.apache.org/jira/browse/IGNITE-3633 Project: Ignite Issue Type: Task Components: binary, cache, SQL Reporter: Alexander Paschenko Assignee: Alexander Paschenko Fix For: 1.8 New binary built keys erroneously get put to cache as having cache code of 0. We want to force user to set hash code explicitly by throwing an exception when they do not do so. Proposed solution by Denis Magda: http://apache-ignite-developers.2346864.n4.nabble.com/All-BinaryObjects-created-by-BinaryObjectBuilder-stored-at-the-same-partition-by-default-td8042i20.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
