[jira] [Comment Edited] (IGNITE-2294) Implement SQL DML (insert, update, delete) clauses.

["Alexander Paschenko (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/IGNITE-2294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15409402#comment-15409402 ] 

Alexander Paschenko edited comment on IGNITE-2294 at 8/5/16 1:19 PM:
---------------------------------------------------------------------

OK, I guess it's time to sum up what has been done by now.

First, in order to make modifying SQL operations possible I had to modify hierarchy of classes corresponding to SQL statements - to do so, class *GridSqlStatement* had been introduced. It's the parent both for *GridSqlQuery* as well as new folks *GridSqlMerge*, *GridSqlInsert*, *GridSqlUpdate*, and *GridSqlDelete*. The reason for introducing common parent is that *GridSqlQuery* has query specific stuff, and mixing it with details for updates would make things rather messy.

Modifying operations take form of familiar *SqlFieldsQuery*, public API is unchanged. What has changed is behavior of *GridSqlQuerySplitter*, *GridReduceQueryExecutor*, and *IgniteH2Indexing* (they now have condition branches/methods to handle update operations).

Results of an update query are returned as a *QueryCursor*<*List*<?>>, just like they would be with any select query. Such a cursor for an update operation bears single *List* element, which in its turn has only one item in it which is number of affected items.

Currently implemented MERGE operation simply utilizes *put*/*putAll* methods of *IgniteCache*.

Binary marshalling support has been added - in order to instantiate and properly populate new objects in binary form, *GridQueryProperty* and *GridQueryTypeDescriptor* had to be changed (to include more information about real types of key and value stored in cache). However, there is an issue with binary marshalling: we don't know hash code of new object at its build time, so we have to come up with something after all. One viable solution seen now is that we supply hash code explicitly, via new 'synthetic' column we will have to introduce - say, _hashcode. Dev list thread:
http://apache-ignite-developers.2346864.n4.nabble.com/All-BinaryObjects-created-by-BinaryObjectBuilder-stored-at-the-same-partition-by-default-td8042.html

While discussing binary marshalling support, one more important problem was discovered - objects without any hash code are simply put to cache with hash code of 0, which hardly is an expected behavior, so it was proposed by Dima that we throw an exception on attempt of putting an object w/o hash code to cache, and Denis Magda suggested that we distinguish objects with hash code of 0 from objects without hash code set at all by using reference comparison - details here:
http://apache-ignite-developers.2346864.n4.nabble.com/All-BinaryObjects-created-by-BinaryObjectBuilder-stored-at-the-same-partition-by-default-tp8042p10330.html

(To be continued)


was (Author: al.psc):
OK, I guess it's time to sum up what has been done by now.

First, in order to make modifying SQL operations possible I had to modify hierarchy of classes corresponding to SQL statements - to do so, class GridSqlStatement had been introduced. It's the parent both for GridSqlQuery as well as new folks GridSqlMerge, GridSqlInsert, GridSqlUpdate, and GridSqlDelete. The reason for introducing common parent is that GridSqlQuery has query specific stuff, and mixing it with details for updates would make things rather messy.

Modifying operations take form of familiar SqlFieldsQuery, public API is unchanged. What has changed is behavior of GridSqlQuerySplitter, GridReduceQueryExecutor, and IgniteH2Indexing (they now have condition branches/methods to handle update operations).

Results of an update query are returned as a QueryCursor<List<?>>, just like they would be with any select query. Such a cursor for an update operation bears single List element, which in its turn has only one item in it which is number of affected items.

Currently implemented MERGE operation simply utilizes put/putAll methods of IgniteCache.

Binary marshalling support has been added - in order to instantiate and properly populate new objects in binary form, GridQueryProperty and GridQueryTypeDescriptor had to be changed (to include more information about real types of key and value stored in cache). However, there is an issue with binary marshalling: we don't know hash code of new object at its build time, so we have to come up with something after all. One viable solution seen now is that we supply hash code explicitly, via new 'synthetic' column we will have to introduce - say, _hashcode. Dev list thread:
http://apache-ignite-developers.2346864.n4.nabble.com/All-BinaryObjects-created-by-BinaryObjectBuilder-stored-at-the-same-partition-by-default-td8042.html

While discussing binary marshalling support, one more important problem was discovered - objects without any hash code are simply put to cache with hash code of 0, which hardly is an expected behavior, so it was proposed by Dima that we throw an exception on attempt of putting an object w/o hash code to cache, and Denis Magda suggested that we distinguish objects with hash code of 0 from objects without hash code set at all by using reference comparison - details here:
http://apache-ignite-developers.2346864.n4.nabble.com/All-BinaryObjects-created-by-BinaryObjectBuilder-stored-at-the-same-partition-by-default-tp8042p10330.html

(To be continued)

> Implement SQL DML (insert, update, delete) clauses.
> ---------------------------------------------------
>
>                 Key: IGNITE-2294
>                 URL: https://issues.apache.org/jira/browse/IGNITE-2294
>             Project: Ignite
>          Issue Type: Wish
>            Reporter: Sergi Vladykin
>            Assignee: Alexander Paschenko
>             Fix For: 1.7
>
>
> We need to add parsing for all the listed SQL commands and translate them into respective cache operations (putIfAbstent, put, remove).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)