I have pushed "zero" version of JDBC updates support, currently without batching (working on it). Sergi, also to make you happy here's another doc with changes to public API: http://goo.gl/FvGKUs
- Alex 2016-08-01 20:06 GMT+03:00 Sergi Vladykin <sergi.vlady...@gmail.com>: > Ok, I think you don't really understand what public API really is, so let > me clarify. What you have described are all internal classes, public API is > what end user will see and work with, like Ignite, IgniteCache, > QueryCursor, etc... All the internal changes do not require any special > discussion, until they are really complex or big or important, so you think > it makes sense to notify everyone about them. > > Here we should not have any public API changes for now and I don't see any > in your doc, so it looks fine to me. > > The only possible issue I see is origKeyClass and origValueClass. These > classes can be unavailable on nodes and most of the time we will have to > work with binary format. Please make sure that this case is correctly > handled. > > Sergi > > 2016-08-01 18:14 GMT+03:00 Alexander Paschenko < > alexander.a.pasche...@gmail.com>: > >> Guys, >> >> Here's documented version of current API changes - it's quite modest >> https://goo.gl/Y6Cv1b >> >> - Alex >> >> 2016-07-28 20:34 GMT+03:00 Alexander Paschenko >> <alexander.a.pasche...@gmail.com>: >> > Sergi, >> > >> > OK, I've done it as you said, thanks. >> > Now working on binary marshaller support. >> > >> > - Alex >> > >> > 2016-07-28 9:08 GMT+03:00 Sergi Vladykin <sergi.vlady...@gmail.com>: >> >> I had a quick look at the PR. >> >> >> >> I don't like this @QueryCacheKey and setKeyProp method on public API. >> They >> >> solve nothing but add complexity and make key to be stored twice in >> cache, >> >> which is wrong. Please remove this. >> >> >> >> If you want to do some public API changes you have to discuss them >> publicly >> >> before implementing them, ok? >> >> >> >> I did not look deeper yet, lets fix the obvious issue first. >> >> >> >> Sergi >> >> >> >> 2016-07-27 21:44 GMT+03:00 Alexander Paschenko < >> >> alexander.a.pasche...@gmail.com>: >> >> >> >>> Sergi, >> >>> >> >>> I've made changes to the API according to your valuable >> >>> recommendations, thank you very much for giving them. Please refer to >> >>> PR to see current state of the work. >> >>> Will surely look into ODBC, .NET and Visor. Though they will most >> >>> likely have to support a new feature rather than considerably change >> >>> existing logic. >> >>> >> >>> - Alex >> >>> >> >>> 2016-07-27 14:23 GMT+03:00 Sergi Vladykin <sergi.vlady...@gmail.com>: >> >>> > Please don't forget about ODBC, .NET and Visor. They all have to >> work in >> >>> > the same way. >> >>> > >> >>> > Sergi >> >>> > >> >>> > 2016-07-27 14:15 GMT+03:00 Alexander Paschenko < >> >>> > alexander.a.pasche...@gmail.com>: >> >>> > >> >>> >> OK, I've found that bold cast to QueryCursor<R> in IgniteCacheProxy >> >>> >> and had a look at how SqlFieldsQuery is used in JDBC driver. Thanks. >> >>> >> >> >>> >> - Alex >> >>> >> >> >>> >> 2016-07-27 13:02 GMT+03:00 Sergi Vladykin <sergi.vlady...@gmail.com >> >: >> >>> >> > Where did you see R in SqlFieldsQuery? >> >>> >> > >> >>> >> > Sergi >> >>> >> > >> >>> >> > 2016-07-27 12:59 GMT+03:00 Alexander Paschenko < >> >>> >> > alexander.a.pasche...@gmail.com>: >> >>> >> > >> >>> >> >> Sergi, >> >>> >> >> >> >>> >> >> But current signature of query() method returns not just some >> >>> >> >> iterator, but rather iterator of R which is type param of Query - >> >>> >> >> i.e., we won't be able to return an int inside a QueryCursor<R>. >> At >> >>> >> >> least without API change (signature of query() method will have >> to be >> >>> >> >> changed to drop genericness, or in some other weird way). Is this >> >>> what >> >>> >> >> we really want? Or am I missing something in your point? >> >>> >> >> >> >>> >> >> - Alex >> >>> >> >> >> >>> >> >> 2016-07-27 12:51 GMT+03:00 Sergi Vladykin < >> sergi.vlady...@gmail.com >> >>> >: >> >>> >> >> > Exactly. This will allow our Jdbc driver to work transparently. >> >>> >> >> > >> >>> >> >> > Sergi >> >>> >> >> > >> >>> >> >> > 2016-07-27 12:40 GMT+03:00 Alexander Paschenko < >> >>> >> >> > alexander.a.pasche...@gmail.com>: >> >>> >> >> > >> >>> >> >> >> Sergi, >> >>> >> >> >> >> >>> >> >> >> You wrote: >> >>> >> >> >> > I'd prefer to return the same information, so it will not be >> >>> empty >> >>> >> >> >> >> >>> >> >> >> Do you mean return iterator with single element that denotes >> >>> number >> >>> >> of >> >>> >> >> >> rows? >> >>> >> >> >> >> >>> >> >> >> Dmitriy, >> >>> >> >> >> >> >>> >> >> >> You wrote: >> >>> >> >> >> > What is the ticket number for this. Is the new API >> documented >> >>> >> there? >> >>> >> >> >> >> >>> >> >> >> Overall issue number is 2294. There's no particular issue on >> API >> >>> >> >> >> changes, but creating one seems to be a good idea, I will do >> it. >> >>> >> >> >> >> >>> >> >> >> - Alex >> >>> >> >> >> >> >>> >> >> >> 2016-07-27 9:20 GMT+03:00 Dmitriy Setrakyan < >> >>> dsetrak...@apache.org>: >> >>> >> >> >> > What is the ticket number for this. Is the new API >> documented >> >>> >> there? >> >>> >> >> >> > >> >>> >> >> >> > On Tue, Jul 26, 2016 at 11:36 AM, Sergi Vladykin < >> >>> >> >> >> sergi.vlady...@gmail.com> >> >>> >> >> >> > wrote: >> >>> >> >> >> > >> >>> >> >> >> >> I don't see anything ugly in empty iterator, sorry if I >> >>> insulted >> >>> >> your >> >>> >> >> >> taste >> >>> >> >> >> >> of beauty. >> >>> >> >> >> >> >> >>> >> >> >> >> If you will take a look at Jdbc, you will see that >> >>> >> >> >> Statement.executeUpdate >> >>> >> >> >> >> method returns number of updated rows, I'd prefer to >> return the >> >>> >> same >> >>> >> >> >> >> information, so it will not be empty (beauty is restored!). >> >>> >> >> >> >> >> >>> >> >> >> >> Sergi >> >>> >> >> >> >> >> >>> >> >> >> >> >> >>> >> >> >> >> >> >>> >> >> >> >> 2016-07-26 18:24 GMT+03:00 Alexander Paschenko < >> >>> >> >> >> >> alexander.a.pasche...@gmail.com>: >> >>> >> >> >> >> >> >>> >> >> >> >> > I see your point. But what about my concerns from initial >> >>> post? >> >>> >> >> >> >> > Particularly about signatures of existing methods? I >> >>> personally >> >>> >> >> don't >> >>> >> >> >> >> > like an option of query() method always returning an >> empty >> >>> >> iterator >> >>> >> >> >> >> > for any non-select query, it seems ugly design wise. >> >>> >> >> >> >> > >> >>> >> >> >> >> > - Alex >> >>> >> >> >> >> > >> >>> >> >> >> >> > 2016-07-26 18:15 GMT+03:00 Sergi Vladykin < >> >>> >> >> sergi.vlady...@gmail.com>: >> >>> >> >> >> >> > > BTW, the simplest way to solve this issue is to allow >> >>> running >> >>> >> SQL >> >>> >> >> >> >> > commands >> >>> >> >> >> >> > > inside of SqlFieldsQuery. >> >>> >> >> >> >> > > >> >>> >> >> >> >> > > We may add some additional convenience API for updates >> if >> >>> we >> >>> >> >> want, >> >>> >> >> >> but >> >>> >> >> >> >> > JDBC >> >>> >> >> >> >> > > client will always call it like this: >> >>> >> >> >> >> > > >> >>> >> >> >> >> > > cache.query(new SqlFieldsQuery("INSERT INTO MY_TABLE >> >>> >> >> >> >> > > VALUES(?,?)").setArgs(1,2)); >> >>> >> >> >> >> > > >> >>> >> >> >> >> > > This will resolve any ambiguity. >> >>> >> >> >> >> > > >> >>> >> >> >> >> > > Sergi >> >>> >> >> >> >> > > >> >>> >> >> >> >> > > 2016-07-26 17:56 GMT+03:00 Sergi Vladykin < >> >>> >> >> sergi.vlady...@gmail.com >> >>> >> >> >> >: >> >>> >> >> >> >> > > >> >>> >> >> >> >> > >> I don't like any pre-parsing, especially with some >> >>> libraries >> >>> >> >> other >> >>> >> >> >> >> than >> >>> >> >> >> >> > >> H2. H2 itself has enough quirks to multiply it on >> quirks >> >>> of >> >>> >> >> another >> >>> >> >> >> >> > library. >> >>> >> >> >> >> > >> >> >>> >> >> >> >> > >> This is exactly what I was talking about - we need >> some >> >>> >> single >> >>> >> >> >> entry >> >>> >> >> >> >> > point >> >>> >> >> >> >> > >> on API for all the SQL commands and queries. Thats >> why I >> >>> >> >> suggested >> >>> >> >> >> >> > >> SqlUpdate to extend Query. To me its is the cleanest >> >>> >> approach. >> >>> >> >> May >> >>> >> >> >> be >> >>> >> >> >> >> we >> >>> >> >> >> >> > >> need to change in some backward compatible way this >> Query >> >>> >> >> >> hierarchy to >> >>> >> >> >> >> > get >> >>> >> >> >> >> > >> rid of extra methods but the idea is still the same. >> >>> >> >> >> >> > >> >> >>> >> >> >> >> > >> Sergi >> >>> >> >> >> >> > >> >> >>> >> >> >> >> > >> 2016-07-26 14:34 GMT+03:00 Alexander Paschenko < >> >>> >> >> >> >> > >> alexander.a.pasche...@gmail.com>: >> >>> >> >> >> >> > >> >> >>> >> >> >> >> > >>> Guys, >> >>> >> >> >> >> > >>> >> >>> >> >> >> >> > >>> I would like to advance the discussion further. >> There's >> >>> one >> >>> >> >> quite >> >>> >> >> >> >> > >>> important question that arose based on current state >> of >> >>> >> work on >> >>> >> >> >> this >> >>> >> >> >> >> > >>> issue. If we use some kind of interactive console, >> like >> >>> >> Visor, >> >>> >> >> >> then >> >>> >> >> >> >> > >>> how should it know whether SQL query it is requested >> to >> >>> >> execute >> >>> >> >> >> >> > >>> returns a result set or not? In JDBC world, solution >> is >> >>> >> quite >> >>> >> >> >> simple >> >>> >> >> >> >> - >> >>> >> >> >> >> > >>> there's base interface called Statement that all >> commands >> >>> >> >> >> implement, >> >>> >> >> >> >> > >>> and it has magic isResultSet method that tells >> whether >> >>> >> >> statement >> >>> >> >> >> is a >> >>> >> >> >> >> > >>> query or an update command. The API proposed now has >> >>> >> separate >> >>> >> >> >> Query >> >>> >> >> >> >> > >>> and Update operations which I believe to be a right >> >>> thing by >> >>> >> >> the >> >>> >> >> >> >> > >>> reasons I outlined in the beginning of this thread. >> >>> However, >> >>> >> >> their >> >>> >> >> >> >> > >>> lack of common ancestor prevents possible console >> clients >> >>> >> from >> >>> >> >> >> >> running >> >>> >> >> >> >> > >>> text SQL commands in a fully transparent manner - >> like >> >>> >> >> >> >> > >>> IgniteCache.execute(String sql). Therefore I see two >> >>> >> possible >> >>> >> >> >> ways of >> >>> >> >> >> >> > >>> solving this: >> >>> >> >> >> >> > >>> >> >>> >> >> >> >> > >>> - we change API so that it includes new class or >> >>> interface >> >>> >> >> >> parenting >> >>> >> >> >> >> > >>> both Query and Update, and clients use it to >> communicate >> >>> >> with >> >>> >> >> >> cache >> >>> >> >> >> >> > >>> - we let (or make :) ) the client determine command >> type >> >>> >> >> >> >> independently >> >>> >> >> >> >> > >>> and behave accordingly - for it to work it will have >> some >> >>> >> kind >> >>> >> >> of >> >>> >> >> >> >> > >>> command parsing by itself just to determine its type. >> >>> Visor >> >>> >> >> >> console >> >>> >> >> >> >> > >>> may use simple library like JSqlParser >> >>> >> >> >> >> > >>> (https://github.com/JSQLParser/JSqlParser; dual LGPL >> >>> >> 2.1/ASF >> >>> >> >> 2.0 >> >>> >> >> >> >> > >>> licensed) to determine request type in terms of >> JDBC, and >> >>> >> >> behave >> >>> >> >> >> >> > >>> accordingly. >> >>> >> >> >> >> > >>> >> >>> >> >> >> >> > >>> Personally, I think that the second approach is >> better - >> >>> and >> >>> >> >> >> here's >> >>> >> >> >> >> > why. >> >>> >> >> >> >> > >>> >> >>> >> >> >> >> > >>> First, it does not seem wise to change API simply to >> make >> >>> >> >> console >> >>> >> >> >> (or >> >>> >> >> >> >> > >>> any other) clients simpler. Programmatic APIs should >> be >> >>> >> concise >> >>> >> >> >> and >> >>> >> >> >> >> > >>> short for programmatic use, console clients should be >> >>> easy >> >>> >> to >> >>> >> >> use >> >>> >> >> >> >> from >> >>> >> >> >> >> > >>> console - and that's it: after all, console client >> >>> exists to >> >>> >> >> free >> >>> >> >> >> a >> >>> >> >> >> >> > >>> user from burden of doing things programmatically, >> so its >> >>> >> aim >> >>> >> >> is >> >>> >> >> >> to >> >>> >> >> >> >> > >>> adapt API to console or whatever UI. >> >>> >> >> >> >> > >>> Second, possible complications in client implied by >> such >> >>> >> >> approach >> >>> >> >> >> >> > >>> certainly won't be dramatic - I don't think that >> >>> additional >> >>> >> >> single >> >>> >> >> >> >> > >>> query parsing operation in client code will make it >> much >> >>> >> >> harder to >> >>> >> >> >> >> > >>> develop. >> >>> >> >> >> >> > >>> Third, as I see it now, adding a new "synthetic" >> entity >> >>> and >> >>> >> new >> >>> >> >> >> >> method >> >>> >> >> >> >> > >>> would take more effort to adapting the client to new >> API. >> >>> >> >> >> >> > >>> >> >>> >> >> >> >> > >>> Dmitry, Sergi, I would like to hear what you think >> about >> >>> it >> >>> >> >> all. >> >>> >> >> >> >> > Thanks. >> >>> >> >> >> >> > >>> >> >>> >> >> >> >> > >>> - Alex >> >>> >> >> >> >> > >>> >> >>> >> >> >> >> > >>> 2016-07-21 21:17 GMT+03:00 Dmitriy Setrakyan < >> >>> >> >> >> dsetrak...@apache.org >> >>> >> >> >> >> >: >> >>> >> >> >> >> > >>> > OK, then using your analogy, the current behavior >> in >> >>> >> Ignite >> >>> >> >> is >> >>> >> >> >> >> MERGE >> >>> >> >> >> >> > for >> >>> >> >> >> >> > >>> > the most part. >> >>> >> >> >> >> > >>> > >> >>> >> >> >> >> > >>> > My preference is that Ignite SQL should work no >> >>> different >> >>> >> >> from >> >>> >> >> >> >> > >>> traditional >> >>> >> >> >> >> > >>> > databases, which means: >> >>> >> >> >> >> > >>> > >> >>> >> >> >> >> > >>> > - INSERT is translated into *putIfAbsent()* call in >> >>> Ignite >> >>> >> >> >> >> > >>> > - UPDATE is translated into *replace()* call in >> Ignite >> >>> >> >> >> >> > >>> > - MERGE is translated into *put()* call in Ignite >> >>> >> >> >> >> > >>> > - For SQL BATCH calls we should delegate to Ignite >> >>> batch >> >>> >> >> >> >> operations, >> >>> >> >> >> >> > >>> e.g. >> >>> >> >> >> >> > >>> > *putAll()* >> >>> >> >> >> >> > >>> > >> >>> >> >> >> >> > >>> > The above should hold true for atomic and >> transactional >> >>> >> >> >> put/putAll >> >>> >> >> >> >> > >>> calls, >> >>> >> >> >> >> > >>> > as well as for the data streamer. >> >>> >> >> >> >> > >>> > >> >>> >> >> >> >> > >>> > Does this make sense? >> >>> >> >> >> >> > >>> > >> >>> >> >> >> >> > >>> > D. >> >>> >> >> >> >> > >>> > >> >>> >> >> >> >> > >>> > On Thu, Jul 21, 2016 at 4:06 AM, Sergi Vladykin < >> >>> >> >> >> >> > >>> sergi.vlady...@gmail.com> >> >>> >> >> >> >> > >>> > wrote: >> >>> >> >> >> >> > >>> > >> >>> >> >> >> >> > >>> >> No, this does not make sense. >> >>> >> >> >> >> > >>> >> >> >>> >> >> >> >> > >>> >> There is no upsert mode in databases. There are >> >>> >> operations: >> >>> >> >> >> >> INSERT, >> >>> >> >> >> >> > >>> UPDATE, >> >>> >> >> >> >> > >>> >> DELETE, MERGE. >> >>> >> >> >> >> > >>> >> >> >>> >> >> >> >> > >>> >> I want to have clear understanding of how they >> have to >> >>> >> >> behave >> >>> >> >> >> in >> >>> >> >> >> >> SQL >> >>> >> >> >> >> > >>> >> databases and how they will actually behave in >> Ignite >> >>> in >> >>> >> >> >> different >> >>> >> >> >> >> > >>> >> scenarios. Also I want to have clear >> understanding of >> >>> >> >> >> performance >> >>> >> >> >> >> > >>> >> implications of each decision here. >> >>> >> >> >> >> > >>> >> >> >>> >> >> >> >> > >>> >> Anything wrong with that? >> >>> >> >> >> >> > >>> >> >> >>> >> >> >> >> > >>> >> Sergi >> >>> >> >> >> >> > >>> >> >> >>> >> >> >> >> > >>> >> On Thu, Jul 21, 2016 at 1:04 PM, Dmitriy >> Setrakyan < >> >>> >> >> >> >> > >>> dsetrak...@apache.org> >> >>> >> >> >> >> > >>> >> wrote: >> >>> >> >> >> >> > >>> >> >> >>> >> >> >> >> > >>> >> > Serj, are you asking what will happen as of >> today? >> >>> Then >> >>> >> >> the >> >>> >> >> >> >> answer >> >>> >> >> >> >> > >>> to all >> >>> >> >> >> >> > >>> >> > your questions is that duplicate keys are not an >> >>> issue, >> >>> >> >> and >> >>> >> >> >> >> Ignite >> >>> >> >> >> >> > >>> always >> >>> >> >> >> >> > >>> >> > operates in **upsert** mode (which is >> essentially a >> >>> >> >> *“put(…)” >> >>> >> >> >> >> > >>> *method). >> >>> >> >> >> >> > >>> >> > >> >>> >> >> >> >> > >>> >> > However, the *“insert”* that is suggested by >> Alex >> >>> would >> >>> >> >> >> delegate >> >>> >> >> >> >> > to >> >>> >> >> >> >> > >>> >> > *“putIfAbsent(…)”*, which in database world >> makes >> >>> more >> >>> >> >> sense. >> >>> >> >> >> >> > >>> However, in >> >>> >> >> >> >> > >>> >> > this case, the *“update”* syntax should >> delegate to >> >>> >> >> >> >> > *“replace(…)”*, >> >>> >> >> >> >> > >>> as >> >>> >> >> >> >> > >>> >> > update should fail in case if a key is absent. >> >>> >> >> >> >> > >>> >> > >> >>> >> >> >> >> > >>> >> > Considering the above, a notion of “*upsert”* or >> >>> >> “*merge” >> >>> >> >> >> >> > *operation >> >>> >> >> >> >> > >>> is >> >>> >> >> >> >> > >>> >> > very much needed, as it will give a user an >> option >> >>> to >> >>> >> >> perform >> >>> >> >> >> >> > >>> >> > “insert-or-update” in 1 call. >> >>> >> >> >> >> > >>> >> > >> >>> >> >> >> >> > >>> >> > Does this make sense? >> >>> >> >> >> >> > >>> >> > >> >>> >> >> >> >> > >>> >> > D. >> >>> >> >> >> >> > >>> >> > >> >>> >> >> >> >> > >>> >> > On Wed, Jul 20, 2016 at 9:39 PM, Sergi Vladykin >> < >> >>> >> >> >> >> > >>> >> sergi.vlady...@gmail.com> >> >>> >> >> >> >> > >>> >> > wrote: >> >>> >> >> >> >> > >>> >> > >> >>> >> >> >> >> > >>> >> > > I'd prefer to do MERGE operation last because >> in >> >>> H2 >> >>> >> it >> >>> >> >> is >> >>> >> >> >> not >> >>> >> >> >> >> > >>> standard >> >>> >> >> >> >> > >>> >> > ANSI >> >>> >> >> >> >> > >>> >> > > SQL MERGE. Or may be not implement it at all, >> or >> >>> may >> >>> >> be >> >>> >> >> >> >> > contribute >> >>> >> >> >> >> > >>> ANSI >> >>> >> >> >> >> > >>> >> > > correct version to H2, then implement it on >> >>> Ignite. >> >>> >> >> Need to >> >>> >> >> >> >> > >>> investigate >> >>> >> >> >> >> > >>> >> > the >> >>> >> >> >> >> > >>> >> > > semantics deeper before making any decisions >> here. >> >>> >> >> >> >> > >>> >> > > >> >>> >> >> >> >> > >>> >> > > Lets start with simple scenarios for INSERT >> and go >> >>> >> >> through >> >>> >> >> >> all >> >>> >> >> >> >> > the >> >>> >> >> >> >> > >>> >> > possible >> >>> >> >> >> >> > >>> >> > > cases and answer the questions: >> >>> >> >> >> >> > >>> >> > > - What will happen on key conflict in TX >> cache? >> >>> >> >> >> >> > >>> >> > > - What will happen on key conflict in Atomic >> >>> cache? >> >>> >> >> >> >> > >>> >> > > - What will happen with the previous two if >> we use >> >>> >> >> >> DataLoader? >> >>> >> >> >> >> > >>> >> > > - How to make these operations efficient (it >> will >> >>> be >> >>> >> >> simple >> >>> >> >> >> >> > enough >> >>> >> >> >> >> > >>> to >> >>> >> >> >> >> > >>> >> > > implement them with separate put/putIfAbsent >> >>> >> operations >> >>> >> >> but >> >>> >> >> >> >> > >>> probably we >> >>> >> >> >> >> > >>> >> > > will need some batching like putAllIfAbsent >> for >> >>> >> >> >> efficiency)? >> >>> >> >> >> >> > >>> >> > > >> >>> >> >> >> >> > >>> >> > > As for API, we still will need to have a >> single >> >>> entry >> >>> >> >> point >> >>> >> >> >> >> for >> >>> >> >> >> >> > >>> all SQL >> >>> >> >> >> >> > >>> >> > > queries/commands to allow any console work >> with it >> >>> >> >> >> >> > transparently. >> >>> >> >> >> >> > >>> It >> >>> >> >> >> >> > >>> >> > would >> >>> >> >> >> >> > >>> >> > > be great if we will be able to come up with >> >>> something >> >>> >> >> >> >> consistent >> >>> >> >> >> >> > >>> with >> >>> >> >> >> >> > >>> >> > this >> >>> >> >> >> >> > >>> >> > > idea on public API. >> >>> >> >> >> >> > >>> >> > > >> >>> >> >> >> >> > >>> >> > > Sergi >> >>> >> >> >> >> > >>> >> > > >> >>> >> >> >> >> > >>> >> > > >> >>> >> >> >> >> > >>> >> > > >> >>> >> >> >> >> > >>> >> > > >> >>> >> >> >> >> > >>> >> > > >> >>> >> >> >> >> > >>> >> > > >> >>> >> >> >> >> > >>> >> > > >> >>> >> >> >> >> > >>> >> > > >> >>> >> >> >> >> > >>> >> > > On Wed, Jul 20, 2016 at 2:23 PM, Dmitriy >> >>> Setrakyan < >> >>> >> >> >> >> > >>> >> > > dsetrak...@gridgain.com> >> >>> >> >> >> >> > >>> >> > > wrote: >> >>> >> >> >> >> > >>> >> > > >> >>> >> >> >> >> > >>> >> > > > 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 >> >>> >> >> >> >> > >>> >> > > > >> >>> >> >> >> >> > >>> >> > > >> >>> >> >> >> >> > >>> >> > >> >>> >> >> >> >> > >>> >> >> >>> >> >> >> >> > >>> >> >>> >> >> >> >> > >> >> >>> >> >> >> >> > >> >> >>> >> >> >> >> > >> >>> >> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >>> >> >> >>> >>
