Thanks Chen. I have added the example to the design docs. Cheers, Abdullah.
Amoudi, Abdullah. On Mon, Jan 18, 2016 at 10:06 PM, Chen Li <[email protected]> wrote: > This example is very illustrative. Many discussions and tickets will > benefit a lot from such good examples. > > Chen > > On Thu, Jan 14, 2016 at 12:15 PM, abdullah alamoudi <[email protected]> > wrote: > > > Example: > > > > data type: [int(pk),int]. > > existing data: > > {1,5} > > > > (case 1) > > upsert {1,5} > > > > This means that in the secondary index update the old secondary key == > the > > new secondary key. Hence, it will be no op. > > > > (case 2 and 3) > > upsert{1,2} > > this means the secondary keys are not equal hence in the secondary > upsert, > > this will happen: > > old key != new key > > (previous value exists which was {5,1}, so we delete it) > > (new value is {2,1} so we insert it). > > > > (case 3 only) > > upsert {2,2} > > since there is no old value, we will only insert the key {2,2} in > secondary > > index. > > > > I hope this made it clearer. If you still need more clarification, let me > > know. > > Cheers, > > Abdullah. > > > > > > Amoudi, Abdullah. > > > > On Thu, Jan 14, 2016 at 11:05 PM, Young-Seok Kim <[email protected]> > > wrote: > > > > > I'm still not clear. > > > (Probably, I'm not clear about the terms used in those cases such as > > > existing secondary key, a different old secondary key, and a different > > new > > > secondary key.) > > > Could you explain the case with an example? :) > > > > > > Thanks, > > > Young-Seok > > > > > > > > > > > > > > > On Thu, Jan 14, 2016 at 11:49 AM, abdullah alamoudi < > [email protected]> > > > wrote: > > > > > >> Young Seok, > > >> In the documentation, 2 and 3 are not mutually exclusive. So you can > > >> think of it as follows: > > >> if we hit 1, we will not hit 2 and 3. > > >> if we don't hit 1, we will definitely do 3. but whether we hit case 2 > > >> depends on whether there was a previous value. > > >> > > >> In another way: > > >> if(case 1){ > > >> return; > > >> } else{ > > >> // case 3 > > >> if (case 2){ > > >> -- do something(case 2) > > >> } > > >> -- do something(case 3) > > >> } > > >> > > >> Does that make sense? > > >> > > >> Amoudi, Abdullah. > > >> > > >> On Thu, Jan 14, 2016 at 10:41 PM, Young-Seok Kim <[email protected]> > > >> wrote: > > >> > > >>> Can someone help me understanding the following part in the upsert > > >>> design document ( > > >>> https://cwiki.apache.org/confluence/display/ASTERIXDB/Upsert) ? > > >>> > > >>> - The secondary Upsert operator perform the following tasks: > > >>> > > >>> > > >>> 1. If the existing secondary key equals to the new secondary key, > it > > >>> is a NO OP. > > >>> 2. If a different old secondary key exists, it deletes the > existing > > >>> secondary key-primary key pair from the secondary index. > > >>> 3. If a different new secondary key exists, it inserts the new > > >>> secondary key-primary key pair from the secondary index. > > >>> > > >>> > > >>> How can the third case happen? > > >>> > > >>> Was there another upsert transaction T1 (upserting record R1 but not > > >>> committed yet) when this transaction T2 reached the secondary index, > > for > > >>> instance? Is this possible? > > >>> I think this example is not valid due to the guarantee of the primary > > >>> key locking in the primary index. T1 must be holding a exclusive lock > > on > > >>> the primary key of R1, so when T2 reached the primary index and read > > the > > >>> R1, it must either be waiting the T1 is over to get a lock on R1 or > > see the > > >>> new record upserted by T1. Thus, when T2 reads from the secondary > > index, it > > >>> must see the value upserted by T2. This is the second case. > > >>> > > >>> Again, how can the third case happen? > > >>> > > >>> Thanks, > > >>> Young-Seok > > >>> > > >>> On Thu, Jan 14, 2016 at 9:37 AM, Jenkins (Code Review) < > > >>> [email protected]> wrote: > > >>> > > >>>> Jenkins has posted comments on this change. > > >>>> > > >>>> Change subject: Add Support for Upsert Operation > > >>>> > ...................................................................... > > >>>> > > >>>> > > >>>> Patch Set 13: Verified-1 > > >>>> > > >>>> Build Unstable > > >>>> > > >>>> https://asterix-jenkins.ics.uci.edu/job/asterix-gerrit-topic/570/ : > > >>>> UNSTABLE > > >>>> > > >>>> -- > > >>>> To view, visit https://asterix-gerrit.ics.uci.edu/477 > > >>>> To unsubscribe, visit https://asterix-gerrit.ics.uci.edu/settings > > >>>> > > >>>> Gerrit-MessageType: comment > > >>>> Gerrit-Change-Id: I8999000331795a5949d621d2dd003903e057a521 > > >>>> Gerrit-PatchSet: 13 > > >>>> Gerrit-Project: asterixdb > > >>>> Gerrit-Branch: master > > >>>> Gerrit-Owner: abdullah alamoudi <[email protected]> > > >>>> Gerrit-Reviewer: Jenkins <[email protected]> > > >>>> Gerrit-Reviewer: Taewoo Kim <[email protected]> > > >>>> Gerrit-Reviewer: Till Westmann <[email protected]> > > >>>> Gerrit-Reviewer: Young-Seok Kim <[email protected]> > > >>>> Gerrit-Reviewer: abdullah alamoudi <[email protected]> > > >>>> Gerrit-HasComments: No > > >>>> > > >>> > > >>> > > >> > > > > > >
