Ouch. Will remove it from the document then :) Cheers, Abdullah.
Amoudi, Abdullah. On Fri, Jan 15, 2016 at 12:17 AM, Young-Seok Kim <[email protected]> wrote: > 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 >>>>>> >>>>> >>>>> >>>> >>> >> >
