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 <[email protected]> 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 <[email protected]>
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 <[email protected]>
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) <
[email protected]> 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 <[email protected]>
Gerrit-Reviewer: Jenkins <[email protected]>
Gerrit-Reviewer: Taewoo Kim <[email protected]>
Gerrit-Reviewer: Till Westmann <[email protected]>
Gerrit-Reviewer: Young-Seok Kim <[email protected]>
Gerrit-Reviewer: abdullah alamoudi <[email protected]>
Gerrit-HasComments: No
