Øystein Grøvlen wrote:
"ST" == Suresh Thalamati <[EMAIL PROTECTED]> writes:
ST> Hi Øystein,
ST> Thanks for reviewing the patch. My answers are in-line...
ST> Øystein Grøvlen (JIRA) wrote:
<snip ...>
ST> By using the catalog approach also backup can only throw a warning
ST> about the deleted container. Once the user deletes a container file ,
ST> there is no way out, users can not even drop that table. I don't think
ST> making backup fail forever when this scenario occurs will be
ST> acceptable to the users.
I agree, but detecting in on backup, gives the user the option of
recovering the table by restoring the previous bakcup.
I agree with you, notifying the user as early as possible about the
missing files is a vey good idea. If there is no previous backup then
detecting and stopping the backup is not a good idea either.
I belive this is not common case scenario, this improvements can
be added later, once I get the online backup/restore to work.
<snip ..>
ST> 2) Move the backing up and unlatching of the page code to the
ST> FileContainer.java.
ST> I have not thought of any other better ways to do design this, any
ST> ideas will be helpful.
Could the backup code be in a separate class instead of part of
RAFContainer? It does not seem to use much of RAFContainer's internal
state.
I think backup code in Rafcontainer.java is ok. Purpose of the
backup code there is to backup the container. Backup needs to
synchronize with the container file deletions and truncation. And also
backup code is just couple of methods in this file, so it may not be
worth creating yet another Class file.
Thanks
-suresht
