> 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

Reply via email to