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, 14 Jan 2016 20:59:56 GMT
They are already handled and there is a test case for them :)

Amoudi, Abdullah.

On Thu, Jan 14, 2016 at 11:58 PM, Mike Carey <dtabass@gmail.com> wrote:

> Note that nulls may have to be carefully handled? (Something to check and
> test thoroughly both for closed and schema-less cases.)  E.g., old was
> null, new is not; new is null, old was not; etc.  (Maybe no problem here,
> but we need all the different test cases - hopefully we have 'em?)
>
> On 1/14/16 12:15 PM, abdullah alamoudi 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