drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neeraja Rentachintala <nrentachint...@maprtech.com>
Subject Re: [DISCUSS] Drop table support
Date Wed, 05 Aug 2015 05:00:57 GMT
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.dunning@gmail.com> wrote:

> On Thu, Jul 30, 2015 at 4:56 PM, Neeraja Rentachintala <
> nrentachintala@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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message