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 >>> >> >> >
