cawaring commented on code in PR #3140:
URL: https://github.com/apache/accumulo/pull/3140#discussion_r1125727302


##########
core/src/main/java/org/apache/accumulo/core/conf/Property.java:
##########
@@ -746,6 +746,8 @@ public enum Property {
       "The number of threads used to delete RFiles and write-ahead logs", 
"1.3.5"),
   GC_TRASH_IGNORE("gc.trash.ignore", "false", PropertyType.BOOLEAN,
       "Do not use the Trash, even if it is configured.", "1.5.0"),
+  GC_TRASH_IGNORE_IMPORTS_ONLY("gc.trash.ignore.imports.only", "false", 
PropertyType.BOOLEAN,
+      "Skip Trash for Import files when the trash is in use.", "3.0.0"),

Review Comment:
   @ctubbsii,  I was actually thinking you were going to take the discussion in 
a different direction and also suggest that we  might consider doing this on a 
per table basis instead of as an all or nothing approach (all tables or no 
tables) as is now.  That it would be better to make this easier and less error 
prone for users instead of having them manage and configure something like 
regexs over Accumulo files in HDFS trash.  From a durability standpoint, we 
allow walogs and replication to be configured on a per table basis.  Trash is 
just another safety net that a user may wish to user.  Some tables can be more 
important than others and allowing that decision to be made on a per table 
basis to include bulk input files, seems like a useful feature.  
   
   I don't see this as Accumulo managing the trash.  I see this as more of 
giving the user explicit control over what Accumulo puts in the trash.    Once 
it is in the trash Accumulo isn't doing anything with it.  
   
   
   
   



-- 
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]

Reply via email to