Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Wed, 10 Apr 2013 15:20:17 +0000 (UTC)
From: "Keith Turner (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12641842.1365603819574.143158.1365607217253@arcas>
In-Reply-To: <JIRA.12641842.1365603819574@arcas>
References: <JIRA.12641842.1365603819574@arcas>
Subject: [jira] [Commented] (ACCUMULO-1256) Add table trash can
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/ACCUMULO-1256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13627897#comment-13627897 ] 

Keith Turner commented on ACCUMULO-1256:
----------------------------------------

bq. Presumably there will be a new configuration property indicating how long to wait before deleting the tables. Do you think this should be global or per-table? Which process will handle actually deleting the tables once they expire?

I think a global/master config option would be good.  Maybe have the master do it.  I have become very untrustworthy of time across nodes.  For aging off fate operations, I made that happen within a master instance.  An instance of the master keeps track of time for each complete FATE op that the client has not finalized.  After 8 hours the master deletes it.   If the master is restarted, then the stopwatch on each complete fate op starts over.  If a master process does not run for 8 hours, it will never delete anything.   This avoids the problem of time being off on different machines.  It does not avoid the problem of time jumping on the node where the master instance is running.  Could do the same thing for tables in trash, a running master keeps track of when each trash table should be deleted.   If the timeout is one hour, then an hour after the master starts all tables that were in the trash when the master started would be deleted.
                
> Add table trash can
> -------------------
>
>                 Key: ACCUMULO-1256
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-1256
>             Project: Accumulo
>          Issue Type: New Feature
>            Reporter: Keith Turner
>
> It may be useful to provide an optional trash feature.  If this feature were enabled, then when a table is deleted it would go into the trash can.  Tables that had been in the trash for a while could would eventually be deleted.  Tables could be undeleted from the trash can.
> What would the API and shell commands look like?  How would multiple tables in the trash can with the same name be handled in the API?  Would/should per table properties and pertable permissions be preserved?  Should these tables in the trash can show up in the monitor in some way?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira