asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From abdullah alamoudi <bamou...@gmail.com>
Subject Re: Question about upsert operation
Date Thu, 21 Jan 2016 11:11:11 GMT
Fixed it in the design docs.

Cheers,
Abdullah.

Amoudi, Abdullah.

On Fri, Jan 15, 2016 at 1:17 AM, Young-Seok Kim <kisskys@gmail.com> 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 <bamousaa@gmail.com>
> 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 <kisskys@gmail.com>
>> 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 <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