> On Friday 16 December 2005 2:16 am, Roger Keays wrote: >On Wednesday 14 December 2005 6:39 pm, Roger Keays wrote: > >>If a developer uses Derby for storage this >>would get cumbersome. Zipping the derby DB >>directory is one approach, but that >>complicates application saves, crash recovery, >>etc. > >>That is what I had in mind. I read the Derby already offers read-only >>access to zipped files so thats already half way there right?
Correct, Derby writes all its i/o through a virtual file system layer, represented by classes in the package org.apache.derby.io. There are three complete implementations of this api: - regular file system - using java.io.* files, mainly RandomAccessFile - Jar/Zip - database files archived into a jar archive, read-only. - Classpath - database files accessible as resources though the class path/loader, read-only There is one partial implementation in the code line: - http - database files accessible on a http server, read-only There is one implementation being worked upon: - an in-memory one, I think someone has posted an intial patch for this. One could try an implementation of this package that stored all logically defined files in a single o/s file. Not sure how easy it would be, jar file format is one option, but it doesn't lend itself to being updatable very easily. Mapping blocks in the single physical file into blocks in the logical file is another, hard problems here are block allocation and re-mapping blocks when files are deleted etc. If you want to continue, this discussion would be best on the developers' list. My itch (not that I'm working on this) would be instead to have more utilities around the jar file format, backup directly into a jar file format, create a read-write copy of a database from a jar file. I wonder if these utilities would address your needs? Dan.
