asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Young-Seok Kim <kiss...@gmail.com>
Subject Re: Question about upsert operation
Date Thu, 14 Jan 2016 20:05:53 GMT
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 <bamousaa@gmail.com>
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 <kisskys@gmail.com>
> 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) <
>> do-not-reply@asterixdb.incubator.apache.org> 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 <bamousaa@gmail.com>
>>> Gerrit-Reviewer: Jenkins <jenkins@fulliautomatix.ics.uci.edu>
>>> Gerrit-Reviewer: Taewoo Kim <wangsaeu@gmail.com>
>>> Gerrit-Reviewer: Till Westmann <tillw@apache.org>
>>> Gerrit-Reviewer: Young-Seok Kim <kisskys@gmail.com>
>>> Gerrit-Reviewer: abdullah alamoudi <bamousaa@gmail.com>
>>> Gerrit-HasComments: No
>>>
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message