Like the idea of merge and insert. I need more time to think about the API changes.
Sergi, what do you think? Dmitriy On Jul 20, 2016, at 12:36 PM, Alexander Paschenko <alexander.a.pasche...@gmail.com> wrote: >> Thus, I suggest that we implement MERGE as a separate operation backed by >> putIfAbsent operation, while INSERT will be implemented via put. > > Sorry, of course I meant that MERGE has to be put-based, while INSERT > has to be putIfAbsent-based. > > 2016-07-20 12:30 GMT+03:00 Alexander Paschenko > <alexander.a.pasche...@gmail.com>: >> Hell Igniters, >> >> In this thread I would like to share and discuss some thoughts on DML >> operations' implementation, so let's start and keep it here. Everyone >> is of course welcome to share their suggestions. >> >> For starters, I was thinking about semantics of INSERT. In traditional >> RDBMSs, INSERT works only for records whose primary keys don't >> conflict with those of records that are already persistent - you can't >> try to insert the same key more than once because you'll get an error. >> However, semantics of cache put is obviously different - it does not >> have anything about duplicate keys, it just quietly updates values in >> case of keys' duplication. Still, cache has putIfAbsent operation that >> is closer to traditional notion of INSERT, and H2's SQL dialect has >> MERGE operation which corresponds to semantics of cache put. Thus, I >> suggest that we implement MERGE as a separate operation backed by >> putIfAbsent operation, while INSERT will be implemented via put. >> >> And one more, probably more important thing: I suggest that we create >> separate class Update and corresponding operation update() in >> IgniteCache. The reasons are as follows: >> >> - Query bears some flags that are clearly redundant for Update (page >> size, locality) >> - query() method in IgniteCache (one that accepts Query) and query() >> methods in GridQueryIndexing return iterators. So, if we strive to >> leave interfaces unchanged, we still will introduce some design >> ugliness like query methods returning empty iterators for certain >> queries, and/or query flags that indicate whether it's an update query >> or not, etc. >> - If some Queries are update queries, then continuous queries can't be >> based on them - more design-wise ugly checks and stuff like that. >> - I'm pretty sure there's more I don't know about. >> >> Comments and suggestions are welcome. Sergi Vladykin, Dmitry >> Setrakyan, your opinions are of particular interest, please advise. >> >> Regards, >> Alex
