abdullah alamoudi has posted comments on this change. Change subject: Fix transaction logs and optimize upserts ......................................................................
Patch Set 5: (6 comments) https://asterix-gerrit.ics.uci.edu/#/c/1554/5/asterixdb/asterix-algebra/src/main/java/org/apache/asterix/algebra/operators/CommitOperator.java File asterixdb/asterix-algebra/src/main/java/org/apache/asterix/algebra/operators/CommitOperator.java: Line 62: public void setVars(List<LogicalVariable> primaryKeyLogicalVars, LogicalVariable upsertVar) { > Seems like a reasonable suggestion Done https://asterix-gerrit.ics.uci.edu/#/c/1554/5/asterixdb/asterix-app/src/test/java/org/apache/asterix/app/bootstrap/TestNodeController.java File asterixdb/asterix-app/src/test/java/org/apache/asterix/app/bootstrap/TestNodeController.java: PS5, Line 163: IFrameWriter > Making this an array is a little opaque,maybe an object with the two fields Done https://asterix-gerrit.ics.uci.edu/#/c/1554/5/asterixdb/asterix-common/src/main/java/org/apache/asterix/common/transactions/ILockManager.java File asterixdb/asterix-common/src/main/java/org/apache/asterix/common/transactions/ILockManager.java: PS5, Line 51: int > I wonder why this was an object in the first place. I don't see any reason There has been some discussions on this. Let's not merge before we get a green light from Till at least. In short (type safety) is the reason behind making it a class https://asterix-gerrit.ics.uci.edu/#/c/1554/5/asterixdb/asterix-common/src/main/java/org/apache/asterix/common/transactions/LogType.java File asterixdb/asterix-common/src/main/java/org/apache/asterix/common/transactions/LogType.java: PS5, Line 28: 6; > Any reason not to make it 5/6 now instead of skipping 5? Hmmm. not breaking existing instances? seemed safer to skip it https://asterix-gerrit.ics.uci.edu/#/c/1554/5/asterixdb/asterix-transactions/src/main/java/org/apache/asterix/transaction/management/opcallbacks/AbstractIndexModificationOperationCallback.java File asterixdb/asterix-transactions/src/main/java/org/apache/asterix/transaction/management/opcallbacks/AbstractIndexModificationOperationCallback.java: PS5, Line 80: byte > Why's this cleaner? Using an enum where appropriate is very clear In this case, it is not about cleanliness. It is about performance. having this be always a single path is better IMO since this gets called on a per tuple basis in the upsert pipeline https://asterix-gerrit.ics.uci.edu/#/c/1554/5/hyracks-fullstack/hyracks/hyracks-storage-am-lsm-btree/src/main/java/org/apache/hyracks/storage/am/lsm/btree/impls/LSMBTree.java File hyracks-fullstack/hyracks/hyracks-storage-am-lsm-btree/src/main/java/org/apache/hyracks/storage/am/lsm/btree/impls/LSMBTree.java: PS5, Line 289: : > Why's that the case, that upsert would only affect the current mutable comp The upsert simply replaces what's in the memory component. The insert checks for duplicates in all components -- To view, visit https://asterix-gerrit.ics.uci.edu/1554 To unsubscribe, visit https://asterix-gerrit.ics.uci.edu/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ice5296267033cd7debe76894c864c6411f761d83 Gerrit-PatchSet: 5 Gerrit-Project: asterixdb Gerrit-Branch: master Gerrit-Owner: abdullah alamoudi <bamou...@gmail.com> Gerrit-Reviewer: Ian Maxon <ima...@apache.org> Gerrit-Reviewer: Jenkins <jenk...@fulliautomatix.ics.uci.edu> Gerrit-Reviewer: abdullah alamoudi <bamou...@gmail.com> Gerrit-HasComments: Yes
