Uh oh!
There was an error while loading. Please reload this page.
PHOENIX-6420 Wrong result when conditional and regular upserts are passed in the same commit batch - #1183
Conversation
…ssed in the same commit batch
tkhurana
commented
Mar 25, 2021
stoty
commented
Mar 25, 2021
💔 -1 overall
This message was automatically generated. |
| conn.createStatement().execute(String.format( | ||
| "UPSERT INTO %s VALUES('a',1,1) ON DUPLICATE KEY UPDATE counter1 = counter1 + 2", tableName)); | ||
| conn.commit(); | ||
| assertRow(conn, tableName, "a", 2, 1); |
There was a problem hiding this comment.
Should not counter1 value be 3? We are upserting 1 for counter1 and counter1=1+2
There was a problem hiding this comment.
I think it's correct as counter1 in the row is 0 from line number 627 or did I confuse myself 💭
There was a problem hiding this comment.
@gokceni@swaroopak if the key already exists, we ignore the values provided in upsert and evaluate the expression on the stored value. So in this the increment happens on '0' which was the previously stored value.
There was a problem hiding this comment.
Cool, that's what I meant with the value from line 627.
| conn.createStatement().execute(String.format( | ||
| "UPSERT INTO %s (pk, counter2) VALUES ('a',125)", tableName)); | ||
| conn.commit(); | ||
| assertRow(conn, tableName, "a", 11, 125); |
There was a problem hiding this comment.
Recommend adding a check that index row is updated as well
There was a problem hiding this comment.
Also how about adding a check for char type column updates?
There was a problem hiding this comment.
There is no index defined yet. This change addresses the problem on the data table.
There was a problem hiding this comment.
I saw createIndex( on line 624 of this function, that is why I was checking.
There was a problem hiding this comment.
That is actually local index
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
| conn.createStatement().execute(String.format( | ||
| "UPSERT INTO %s VALUES('a',1,1) ON DUPLICATE KEY UPDATE counter1 = counter1 + 2", tableName)); | ||
| conn.commit(); | ||
| assertRow(conn, tableName, "a", 9, 4); |
There was a problem hiding this comment.
To see these switched could be nice like row 635 and 634 swapped so that we are sure they are in the same batch and the order doesn't matter in the batch.
| } else { | ||
| boolean incrementRowCount = dstMutations == this.mutationsMap; | ||
| // we only need to check if the new mutation batch (srcRows) conflicts with the | ||
| // last mutation batch |
There was a problem hiding this comment.
why? could you add it to the comment
There was a problem hiding this comment.
Because we only try to merge the new batch with the last one. That is why we only check for conflicts with the last one. All previous batches are not updated.
stoty
commented
Mar 26, 2021
💔 -1 overall
This message was automatically generated. |
| import java.util.List; | ||
| import java.util.Properties; | ||
| import com.google.common.collect.ImmutableList; |
There was a problem hiding this comment.
good to use the shaded version of guava for easier porting to 5.x
There was a problem hiding this comment.
@gjacoby126 I opened this PR against apache 4.x. The version on master is already using the shaded version.
| assertEquals(2, state.getNumRows()); | ||
| int actualPairs = 0; | ||
| Iterator<Pair<byte[], List<Mutation>>> mutations = state.toMutations(); |
There was a problem hiding this comment.
A comment here on what you're checking would be helpful.
Uh oh!
There was an error while loading. Please reload this page.
| if (multiRowMutationState != null) { | ||
| final List<Mutation> deleteMutations = Lists.newArrayList(); | ||
| generateMutations(key, mutationTimestamp, serverTimestamp, multiRowMutationState, deleteMutations, null); | ||
| // for index table there will only be 1 mutation batch in the list |
There was a problem hiding this comment.
why only one mutation batch? What if there are conflicting batches for the index?
There was a problem hiding this comment.
@gjacoby126 For indexes, the only time we see an entry in the map is in case of deletes and that too for immutable indexes. So I don't expect a conflicting update unless someone explicitly does a regular upsert and conditional upsert directly on index table which is theoretically possible but highly unlikely.
stoty
commented
Apr 5, 2021
💔 -1 overall
This message was automatically generated. |
* PHOENIX-6420 Wrong result when conditional and regular upserts are passed in the same commit batch (apache#1183) * PHOENIX-6420 Wrong result when conditional and regular upserts are passed in the same commit batch * Addressed feedback * Added comments, rename variable * PHOENIX-6387 Conditional updates on tables with indexes (apache#1215) * PHOENIX-6387 Conditional updates on tables with indexes client side * PHOENIX-6387 Conditional updates on tables with indexes server side * Remove the extra read For regular upserts on tables with local index * Addressed review comments
No description provided.