[
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)
