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