On Thu Oct 16 13:34:01 2008, MLAWREN wrote:
Show quoted text>
> One of my packages once received a bug referring to the use of temporary
> files with predictable names.
>
>
http://rt.cpan.org/Public/Bug/Display.html?id=30019
>
> which can apparently be bad news, particularly if tests are run as root.
>
> The suggestion was made to use File::Temp for
>
> a) creating non-predictable file names; and
> b) removing tempory files/directories on cleanup
>
> Could the same concerns and solution apply here?
The same concerns definitely apply here.
Non predictable file names will prevent Test::Database to find back the
database information that is created, and meant to be passed between
tests scripts. So using File::Temp is definitely not an option. We
could make the directory name less predictable by adding some random
information taken on the local system. But I still have to make sure
that Test::Database->base_dir() will always return the same value on a
given system.
However, removing the temporary files can be done with a
Test::Database->cleanup() in the last test script.
Show quoted text> A secondary issue is this: what happens when a user runs multiple
> Test::Database tests on the same system. Is there a chance for
> over-writing and race conditions for /tmp/Test-Database/user/?
Yes, there is. Again, if we want to take advantage of databases nicely
provided by the host owner, I don't see many ways to avoid this. Adding a
locking scheme will not help much, if a script that expects the database
to be left in a certain state by the previous test script is started
some other script that just happened to be run at that time.
Show quoted text> I would also find it somewhat cleaner if a temporary files were created
> underneath the t/ directory, but I have no logic for that other than
> personal preference.
Yes, I understand.
I would say we have several distinct use cases:
1) using databases provided by the host system
(by way of env vars, configuration)
2) fully setting up the database in a local directory
In case 1), we can't avoid race conditions and test scripts stepping on
each other's toes. The gain is that we get many more available databases
systems (e.g., I doubt I'll ever write a Test::Database::Oracle, but a
CPAN test could provide the connection information to one).
In case 2), we can do whatever we want, including having base_dir()
point inside of t/ and do its stuff there.
I also see a case 1 1/2, where the database information we are given
comes with full administrative rights on the database, which allows us
to create and drop databases. In that case, we can effectively ensure
we have our own private database, and that any new database that will
be created will have a different name.
What do you think?
-- BooK
