[
https://issues.apache.org/jira/browse/DERBY-5232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13493880#comment-13493880
]
Knut Anders Hatlen commented on DERBY-5232:
-------------------------------------------
I think the database will be created in a subdirectory under system/singleUse,
and the name will vary depending on the number of single-use databases created
earlier in the test run. So to find the database directory, you'd need
something like this:
TestConfiguration config = TestConfiguration.getCurrent();
File readMeFile = new File(
config.getDatabasePath(config.getDefaultDatabaseName()),
DB_README_FILE_NAME);
The new assert methods could be simplified by using helper methods from the
PrivilegedFileOpsForTests class (would avoid the need for doPrivileged()
blocks).
The test runs in both embedded and client/server mode. However, it only creates
the database once, so starting the server and re-checking that the files still
exist doesn't add much value. I'd suggest that you replace the defaultSuite()
decorator with embeddedSuite() in the suite() method so that it only runs once.
(If you make this change, you may also have to add a getConnection() call to
the test case to get the database created. defaultSuite() adds some decorators
that will call getConnection() before running the test, but I don't think
embeddedSuite() does that.)
The test should also delete the logDevice directory when it's done, as that
won't be done automatically by DropDatabaseSetup. It should probably be done by
the decorator returned by Decorator.logDeviceAttributeDatabase() and not by the
test itself.
Some nits:
- The new file uses a mix of tabs and spaces for indentation
- I'd prefer braces in the if statement in
Decorator.logDeviceAttributeDatabase() (my IDE shows a warning because of the
missing braces). Or perhaps just remove the null check, as those tests that
want to use the default logDevice, should not use this decorator.
> Put a stern README file in log and seg0 directories to warn users of
> corrpution they will cause if they touch files there
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-5232
> URL: https://issues.apache.org/jira/browse/DERBY-5232
> Project: Derby
> Issue Type: Improvement
> Components: Store
> Affects Versions: 10.8.1.2
> Reporter: Kathey Marsden
> Assignee: Mamta A. Satoor
> Fix For: 10.10.0.0
>
> Attachments: DERBY5232_patch1_diff.txt, DERBY5232_patch1_stat.txt,
> DERBY5232_patch2_diff.txt, DERBY5232_patch2_stat.txt,
> DERBY5232_patch3_diff.txt, DERBY5232_patch3_stat.txt,
> DERBY5232_patch4_diff.txt, DERBY5232_patch4_stat.txt,
> DERBY5232_patch5_diff.txt, DERBY5232_patch5_stat.txt,
> DERBY5232_patch6_diff.txt, DERBY5232_patch6_stat.txt,
> DERBY5232_patch7_diff.txt, DERBY5232_patch7_stat.txt,
> DERBY5232_test_patch1_diff.txt, DERBY5232_test_patch1_stat.txt
>
>
> Users often on bad advice or desperation touch or delete files in the log or
> seg0 directories (mostly log).
> I think it would be good for new databases and on upgrade that a file be
> created in these directories with a name like:
> TOUCHING_FILES_HERE_WILL_CORRUPT_DB_README.txt
> or some such to warn of the perils of doing this and the corrupting effects
> and how it can eliminate any possibility of salvage. It should also encourage
> users to make a zip backup of the database directory with no jvm currently
> accessing it before trying to do anything with the database if it appears to
> be already corrupt. Also point to backup/restore documentation and encourage
> restore of a good backup into an empty directory if the database is corrupt.
> I'm not sure if it would help but it couldn't hurt.
--
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
