Vladimir, Igniters,
I’m editing the new version of our SELECT page [1] that initially consisted of the content fully copied from H2. For instance, there we had the following statement that’s not true for Ignite: "If FOR UPDATE is specified, the tables are locked for writing. When using MVCC, only the selected rows are locked as in an UPDATE statement. In this case, aggregate, GROUP BY, DISTINCTqueries or joins are not allowed in this case." How do we process FOR UPDATE parameter in Ignite right now? Please do a proof-read of the page at all confirming the rest data applies for Ignite. [1] https://apacheignite-sql.readme.io/v2.1/docs/select — Denis |
Vladimir, Alex P.,
In addition to that please review INSERT, UPDATE, DELETE, MERGE commands syntax. Are all the parameters (DIRECT, SORTED, etc.) supported by Ignite and if, yes, then how? I’m doubt that Ignite fully supports H2 syntax: https://apacheignite-sql.readme.io/v2.1/docs/dml — Denis > On Oct 18, 2017, at 2:02 PM, Denis Magda <[hidden email]> wrote: > > Vladimir, Igniters, > > I’m editing the new version of our SELECT page [1] that initially consisted of the content fully copied from H2. > > For instance, there we had the following statement that’s not true for Ignite: "If FOR UPDATE is specified, the tables are locked for writing. When using MVCC, only the selected rows are locked as in an UPDATE statement. In this case, aggregate, GROUP BY, DISTINCTqueries or joins are not allowed in this case." > > How do we process FOR UPDATE parameter in Ignite right now? Please do a proof-read of the page at all confirming the rest data applies for Ignite. > > [1] https://apacheignite-sql.readme.io/v2.1/docs/select > > — > Denis |
Hi Denis,
"FOR UPDATE" is not supported at the moment. We will add it's support for transactional case [1]. In non-transactional case it would behave in the same way as normal SELECT. [1] https://issues.apache.org/jira/browse/IGNITE-6937 On Thu, Oct 19, 2017 at 3:21 AM, Denis Magda <[hidden email]> wrote: > Vladimir, Alex P., > > In addition to that please review INSERT, UPDATE, DELETE, MERGE commands > syntax. Are all the parameters (DIRECT, SORTED, etc.) supported by Ignite > and if, yes, then how? I’m doubt that Ignite fully supports H2 syntax: > https://apacheignite-sql.readme.io/v2.1/docs/dml > > — > Denis > > > On Oct 18, 2017, at 2:02 PM, Denis Magda <[hidden email]> wrote: > > > > Vladimir, Igniters, > > > > I’m editing the new version of our SELECT page [1] that initially > consisted of the content fully copied from H2. > > > > For instance, there we had the following statement that’s not true for > Ignite: "If FOR UPDATE is specified, the tables are locked for writing. > When using MVCC, only the selected rows are locked as in an UPDATE > statement. In this case, aggregate, GROUP BY, DISTINCTqueries or joins are > not allowed in this case." > > > > How do we process FOR UPDATE parameter in Ignite right now? Please do a > proof-read of the page at all confirming the rest data applies for Ignite. > > > > [1] https://apacheignite-sql.readme.io/v2.1/docs/select > > > > — > > Denis > > |
On Mon, Nov 27, 2017 at 11:33 PM, Vladimir Ozerov <[hidden email]>
wrote: > Hi Denis, > > "FOR UPDATE" is not supported at the moment. We will add it's support for > transactional case [1]. In non-transactional case it would behave in the > same way as normal SELECT. > Why only for transactional cases? Why can't we lock for non-transactional cases as well? |
I do not see any use case for this. Why would you want to do this?
On Tue, Nov 28, 2017 at 11:18 AM, Dmitriy Setrakyan <[hidden email]> wrote: > On Mon, Nov 27, 2017 at 11:33 PM, Vladimir Ozerov <[hidden email]> > wrote: > > > Hi Denis, > > > > "FOR UPDATE" is not supported at the moment. We will add it's support for > > transactional case [1]. In non-transactional case it would behave in the > > same way as normal SELECT. > > > > Why only for transactional cases? Why can't we lock for non-transactional > cases as well? > |
On Tue, Nov 28, 2017 at 12:34 AM, Vladimir Ozerov <[hidden email]>
wrote: > I do not see any use case for this. Why would you want to do this? > Atomic cache supports locking to my knowledge. The use case would be identical in SQL use case - to lock a row. Why not? |
In this case you lock rows, but there are not subsequent operation which
will use this lock. FOR UPDATE only makes sense as a part of transaction. On Tue, Nov 28, 2017 at 4:56 PM, Dmitriy Setrakyan <[hidden email]> wrote: > On Tue, Nov 28, 2017 at 12:34 AM, Vladimir Ozerov <[hidden email]> > wrote: > > > I do not see any use case for this. Why would you want to do this? > > > > Atomic cache supports locking to my knowledge. The use case would be > identical in SQL use case - to lock a row. Why not? > |
Free forum by Nabble | Edit this page |