asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chen Li <che...@gmail.com>
Subject Re: Question about upsert operation
Date Mon, 18 Jan 2016 18:06:32 GMT
This example is very illustrative.  Many discussions and tickets will
benefit a lot from such good examples.

Chen

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