You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Stephen Fitch <05...@acadiau.ca> on 2005/09/23 19:14:28 UTC

Derby In-Memory Functionality ideas

Hello.

I am currently working on adding in-memory functionality to derby as a 
topic for my undergraduate honours thesis.

I don't have a whole lot of experience with this level of OO or open 
source so I just want to throw some ideas by the derby community and get 
a sense if I'm going in the right direction.

Ideas so far...

1: new in-memory implementation of StorageFactory interface 
(org.apache.derby.impl.io.MemoryStorageFactory) implementing 
WritableStorageFactory

-add some kind of structure (HashTable, Vector, ..?) to contain all the 
data now written stored memory instead of files. They'd be keyed by 
their full pathnames.

ex:
file db.lck in database "test1", in system directory /home/derby/dat
full path would be /home/derby/dat/test1/db.lck
Using that full path as a key in a HashTable would get some kind of 
object compatible with java.io.InputStream and java.io.OutputStream. 
Exactly what kind of object that would be in place of a file, I'm not 
quite sure what would be appropriate. 
org.apache.derby.iapi.services.io.DynamicByteArrayOutputStream looks 
like an interesting candidate though.

2: new in-memory implementation of StorageFile interface 
(org.apache.derby.impl.io.MemoryFile)

-similar to InputFileStream's constructor, every MemoryFile would 
reference its creating MemoryStorageFactory (the same one since there's 
only one storagefactory) to be able to pass off things like mkdirs() or 
createNewFile() to the MemoryStorageFactory. This allows the storage 
factory to add/modify the entry in the new "table" of filenames and get 
input and output streams etc.

3: new in-memory implementation of StorageRandomAccessFile 
(org.apache.derby.impl.io.MemoryRandomAccessFile). I don't think this is 
necessary yet as derby should be ok handling just input and output 
streams for now(</guess>). Can be implemented later.

4: Something will need to be done with derby's temporary files. Will 
look into this later.

That's all I've come up with so far. Hopefully it was as coherent in 
text form as in my head.

I am open to any new ideas or suggestions as well as others interested 
in collaborating on this feature :)

Thanks,




Stephen Fitch
Acadia University