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