[
https://issues.apache.org/jira/browse/DERBY-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12675713#action_12675713
]
chatom edited comment on DERBY-646 at 2/22/09 3:09 PM:
---------------------------------------------------------------
Hi folks,
Attached (derby-646-20090222.stat, derby-646-20090222.diff) is my
implementation of the interfaces
org.apache.derby.io.{StorageFile,StorageRandomAccessFile,WritableStorageFactory}
such that all file system operations are emulated entirely in memory,
producing no file or directory on disk.
A brief description of the content:
- java\engine\org\apache\derby\impl\io\memory
This directory contains the source files for the implementation of the
database storage factory interfaces.
- java\testing\org\apache\derbyTesting\functionTests\tests\memoryIO
This directory contains the source files for the JUnit tests. It consists of
three sets of fairly extensive unit tests of the basic building blocks of my
implementation. They started out as five sets of stand-alone JUnit tests and
were converted to conform to Derby's JUnit test framework. In the process of
conversion, two sets of stand-alone tests were dropped because they use on-disk
operations to verify the correctness of in-memory operations, and Derby's test
framework does not allow arbitrary operations on disk, as far as I can tell.
These unit tests run only in the embedded mode of Derby's test framework,
because they make no DB connections.
In addition, there is one functional test consisting of a simple but
non-trivial clustering application. It is non-trivial because clustering is an
important application in many engineering and scientific disciplines; it is
simple in that it computes clustering of numerical data in one dimensional
space -- the simplest case. The application implements the same algorithm in
both JAVA (computed by the JUnit test case object itself) and SQL (computed by
Derby using the in-memory storage factory) and cross-checks the computed
results, within some floating-point tolerance. The SQL portion of the
application computes quite a few CREATE, INSERT, DELETE, SELECT, JOIN, GROUP
BY, ORDER BY, DROP; and so should exercise the storage layer to a good extent.
This functional test runs in both the embedded mode and the client mode of
Derby's test framework.
The sub-sub-protocol associated with this in-memory storage factory is named
"memory". So the connection string looks like "jdbc:derby:memory:MyTestDb" or
"jdbc:derby://localhost:1527/memory:MyTestDb".
-----
HELP!!! I've gotten the tests compiled properly with "ant all". The compiled
class files show up under
"classes\org\apache\derbyTesting\functionTests\tests\memoryIO". But again I'm
running into the problem of not knowing how to get them included in the
"derbyTesting.jar" file.
Nor did I figure out how to have them automatically executed with "ant
junit-all", "ant junitreport", etc. For now, this is what I do after "ant all"
to execute the tests on Windows:
java -cp .\tools\java\junit.jar;.\classes junit.textui.TestRunner
org.apache.derbyTesting.functionTests.tests.memoryIO._Suite
(BTW, when I execute the above command, the disk activity LED on my computer
goes wild during the functional test. That doesn't happen with the stand-alone
version of the same functional test (before conversion to run under Derby's
test framework). Perhaps I have mis-configured something in the test object
itself such that the above command does not actually test the in-memory storage
factory?)
-----
Existing files modified by this patch:
- java\engine\org\apache\derby\impl\build.xml
tools\jar\extraDBMSclasses.properties
These two files were modified so that my implementation would be compiled and
included in Derby's JAR files.
- java\engine\org\apache\derby\iapi\services\monitor\PersistentService.java
java\engine\org\apache\derby\impl\services\monitor\BaseMonitor.java
These two files were modified only because I did not feel like typing
"-Dderby.subSubProtocol.memory=org.apache.derby.impl.io.memory.MemoryStorageFactory"
for every run. I simply added a mapping from the "memory" service to the
"org.apache.derby.impl.io.memory.MemoryStorageFactory" class in BaseMonitor.
- java\testing\build.xml
This file was modified so that my tests would be compiled into class files
under "classes\org\apache\derbyTesting\functionTests\tests\memoryIO".
-----
Thanks.
was (Author: chatom):
Hi folks,
Attached (derby-646-20090222.stat, derby-646-20090222.diff) is my
implementation of the interfaces
org.apache.derby.io.{StorageFile,StorageRandomAccessFile,WritableStorageFactory}
such that all file system operations are emulated entirely in memory,
producing no file or directory on disk.
A brief description of the content:
- java\engine\org\apache\derby\impl\io\memory
This directory contains the source files for the implementation of the
database storage factory interfaces.
- java\testing\org\apache\derbyTesting\functionTests\tests\memoryIO
This directory contains the source files for the JUnit tests. It consists of
three sets of fairly extensive unit tests of the basic building blocks of my
implementation. They started out as five sets of stand-alone JUnit tests and
were converted to conform to Derby's JUnit test framework. In the process of
conversion, two sets of stand-alone tests were dropped because they use on-disk
operations to verify the correctness of in-memory operations, and Derby's test
framework does not allow arbitrary operations on disk, as far as I can tell.
These unit tests run only in the embedded mode of Derby's test framework,
because they make no DB connections.
In addition, there is one functional test consisting of a simple but
non-trivial clustering application. It is non-trivial because clustering is an
important application in many engineering and scientific disciplines; it is
simple in that it computes clustering of numerical data in one dimensional
space -- the simplest case. The application implements the same algorithm in
both JAVA (computed by the JUnit test case object itself) and SQL (computed by
Derby using the in-memory storage factory) and cross-checks the computed
results, within some floating-point tolerance. The SQL portion of the
application computes quite a few CREATE, INSERT, DELETE, SELECT, JOIN, GROUP
BY, ORDER BY, DROP; and so should exercise the storage layer to a good extent.
This functional test runs in both the embedded mode and the client mode of
Derby's test framework.
The sub-sub-protocol associated with this in-memory storage factory is named
"memory". So the connection string looks like "jdbc:derby:memory:MyTestDb" or
"jdbc:derby://localhost:1527/memory:MyTestDb".
-----
HELP!!! I've gotten the tests compiled properly with "ant all". The compiled
class files show up under
"classes\org\apache\derbyTesting\functionTests\tests\memoryIO". But again I'm
running into the problem of not knowing how to get them included in the
"derbyTesting.jar" file.
Nor did I figure out how to have them automatically executed with "ant
junit-all", "ant junitreport", etc. For now, this is what I do after "ant all"
to execute the tests on Windows:
java -cp .\tools\java\junit.jar;.\classes junit.textui.TestRunner
org.apache.derbyTesting.functionTests.tests.memoryIO._Suite
-----
Existing files modified by this patch:
- java\engine\org\apache\derby\impl\build.xml
tools\jar\extraDBMSclasses.properties
These two files were modified so that my implementation would be compiled and
included in Derby's JAR files.
- java\engine\org\apache\derby\iapi\services\monitor\PersistentService.java
java\engine\org\apache\derby\impl\services\monitor\BaseMonitor.java
These two files were modified only because I did not feel like typing
"-Dderby.subSubProtocol.memory=org.apache.derby.impl.io.memory.MemoryStorageFactory"
for every run. I simply added a mapping from the "memory" service to the
"org.apache.derby.impl.io.memory.MemoryStorageFactory" class in BaseMonitor.
- java\testing\build.xml
This file was modified so that my tests would be compiled into class files
under "classes\org\apache\derbyTesting\functionTests\tests\memoryIO".
-----
Thanks.
> In-memory backend storage support
> ---------------------------------
>
> Key: DERBY-646
> URL: https://issues.apache.org/jira/browse/DERBY-646
> Project: Derby
> Issue Type: New Feature
> Components: Store
> Environment: All
> Reporter: Stephen Fitch
> Attachments: derby-646-1a-raw-compiles.diff,
> derby-646-1a-raw-compiles.stat, derby-646-20090222.diff,
> derby-646-20090222.stat, derby-646-2a-vfmem_first_rev.diff,
> derby-646-2a-vfmem_first_rev.stat, svn.diff
>
>
> To allow creation and modification of databases in-memory without requiring
> disk access or space to store the database.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.