Ted, thats fair point on the recovery part. Regarding the other point by Mehant (copied below) ,there is an implication that user can drop only Drill managed tables (i.e created as Drill user) when security is not enabled. I think this check is too restrictive (also unintuitive). Drill doesn't have the concept of external/managed tables and a user (impersonated user if security is enabled or Drillbit service user if no security is enabled) should be able to drop the table if they have permissions to do so. The above design proposes a check to verify if the files that need to be deleted are readable by Drill and I believe is a good validation to have.
/The above check is in the case when security is not enabled. Meaning we are executing as the Drill user. If we are running as the Drill user (which might be root or a super user) its likely that this user has permissions to delete most files and checking for permissions might not suffice. So when security isn't enabled the proposal is to delete only those files that are owned (created) by the Drill user./ On Fri, Jul 31, 2015 at 12:09 AM, Ted Dunning <ted.dunn...@gmail.com> wrote: > On Thu, Jul 30, 2015 at 4:56 PM, Neeraja Rentachintala < > nrentachint...@maprtech.com> wrote: > > > Also will there any mechanism to recover once you accidentally drop? > > > > yes. Snapshots <https://www.mapr.com/resources/videos/mapr-snapshots>. > > Seriously, recovery of data due to user error is a platform thing. How can > we recover from turning off the cluster? From removing a disk on an Oracle > node? > > I don't think that this is Drill's business. >
