Thanks for the example which makes the case clear. I think I was confused by the phrase "if a different new secondary key exists".
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 >>>>> >>>> >>>> >>> >> >
