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:38 GMT
Thanks Chen.
I have added the example to the design docs.

Cheers,
Abdullah.

Amoudi, Abdullah.

On Mon, Jan 18, 2016 at 10:06 PM, Chen Li <chenli@gmail.com> wrote:

> 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