keith-turner commented on code in PR #3640:
URL: https://github.com/apache/accumulo/pull/3640#discussion_r1277783790
##########
server/manager/src/main/java/org/apache/accumulo/manager/TabletGroupWatcher.java:
##########
@@ -789,8 +795,66 @@ private void mergeMetadataRecords(MergeInfo info) throws
AccumuloException {
for (Entry<Key,Value> entry : scanner) {
Key key = entry.getKey();
Value value = entry.getValue();
+
+ final KeyExtent keyExtent = KeyExtent.fromMetaRow(key.getRow());
+
+ // Keep track of the last Key Extent seen so we can use it to fence
+ // of RFiles when merging the metadata
+ if (lastRow != null && !keyExtent.equals(lastRow)) {
+ previousKeyExtent = lastRow;
+ }
+
+ // Special case for now to handle the highest/stop tablet which is
where files are
+ // merged to so we need to handle the deletes on update here as it
won't be handled later
+ // TODO: Can this be re-written to not have a special edge case and
make it simpler?
+ if (keyExtent.equals(stopExtent)) {
+ if (previousKeyExtent != null
+ && key.getColumnFamily().equals(DataFileColumnFamily.NAME)) {
+
+ // Delete exiting metadata as we are now adding a range
+ m.putDelete(key.getColumnFamily(), key.getColumnQualifier());
Review Comment:
If a mutation has an add and delete for the same key, it may ultimately be
deleted. So it could be more than an optimization, may be needed for
correctness but not completely sure. It depends on what timestamp each entry
from the mutation gets on the server side. When two keys have the same
timestamp and one is a delete, then the delete will sort first hiding the non
delete.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
