I thought that you could also do this by modifying
org/apache/derby/module.properties (as available in your classpath).
I'm not sure what entry to modify, but this is what is used to identify
what implementation use for various interfaces (such as StorageFactory).
David
Francois Orsini wrote:
Luigi,
On 3/29/07, *Francois Orsini* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Regarding A) You might want to look at some of the proposed and
pending changes for in-memory database / storage support:
https://issues.apache.org/jira/browse/DERBY-646
<https://issues.apache.org/jira/browse/DERBY-646>
Check the very first comments as a possible way.
You would probably need to change some of the tests properties to use a
different default URL instead (if going the way it is mentioned in
JIRA-646 and specify the storage factory to use)...
Btw, you might want to create a new JIRA entry (if none already
exists) for this new storage factory implementation. Just my 0.02 cents,
Saw that you're working on
http://issues.apache.org/jira/browse/DERBY-2469 ;-) forget the above
Regarding B) I guess you could also run the 'multi' (stress) test
suite on top of storeall
HTH
On 3/29/07, *Luigi Lauro* < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
By checking the README.htm provided in the SVN testing directory, I
can see there is a "storeall" testing suite which seems to test the
storage area.
Now, given I'm working on a new StorageFactory implementation, I
would like to know 2 things:
A) How can I enable my storageFactory as default for testing?
How can
I tell derby to use mine JNLPStorageFactory instead of default one?
B) How much can I trust these tests? How much do they stress the
StorageFile/StorageFactory implementations? They are 'large enough'
so that I can safely trust an implementation if all storeall is
passed, or Do i need to provide more, specific test-case in order to
be safe of my StorageFactory/StorageFile implementation?
Thanks a lot for any help you may give :)
