Great to see you working on this, Kristian. Regarding the CLA, we went
through this a while ago, and yes, it is sufficient.
David
Kristian Waagan (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-646?page=all ]
Kristian Waagan updated DERBY-646:
----------------------------------
Attachment: derby-646-1a-raw-compiles.diff
derby-646-1a-raw-compiles.stat
'derby-646-1a-raw-compiles.diff' is a minor fix of the original patch
'svn.diff'. The patch now applies to trunk and compiles. No other
clean-ups/changes have been done, but I had to rewrite a little bit to solve
circular compile dependencies.
As far as I can tell, the basic functionality is working. I was able to run with the
memory storage backend, which creates a database directory with lock files and a tmp
directory. Tried running a few tests with a "hacked" JDBCClient implementation,
and the tests passed. Had some problems with warnings regarding dual boot (missing
shutdown/clean-up?).
I think a little more clean-up should be done first (implement a missing method
- getURL, remove commented out code, add some more comments), and then the
patch can be reviewed for functional/design improvements.
We might want some tests written specifically for the memory backend, and then
run the existing tests with the memory backend as well.
Stephen Fitch is listed at http://people.apache.org/~jim/committers.html under
"Unlisted CLAs". Is this enough to allow us to safely bring this code into the
repository?
In-memory backend storage support
---------------------------------
Key: DERBY-646
URL: http://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, svn.diff
To allow creation and modification of databases in-memory without requiring
disk access or space to store the database.
