Michael Segel 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?
Uhm no.
http://db.apache.org/derby/docs/10.1/devguide/cdevdeploy11201.html#cdevdeploy11201
?
OOo uses a similar approach with its file format. The hsqldb jdbc driver
is modified/extended to use an alternate IO stream which reads and
writes to and from the compressed file. I don't have the source in front
of me but from memory it works something like that.
Roger
Think beyond "persistence of the object".
Its funny. J. Roy was just in town today. Kinda touched on this issue.
If you want, take a look at how postgress does their storage. The use of a
Tablespace. A tablespace is tied to a chunk which is your "single file"
storage unit. Only you don't just want to stop with a single chunk. (Cooked
or Raw) Then you hit limits. What a 32-bit FS would limit you to 2GB per
file? Also doesn't scale well. So if you have multiple table spaces you can
grow fairly large.
Now if Derby did something like this, and cleaned up some troublesome bugs,
then you'd have a *real* database that could easily compete with the front
runners for about 70% of the DB Space. The other 30% would require a
commercial grade product.
Note I don't suggest following how Postgress does something. just that their
code is in the public domain and you can use it for an educational template.
--
----------------------------------------
Ninth Avenue Software
p: +61 7 3870 8494 (UTC +10)
f: +61 7 3870 8491
w: http://www.ninthavenue.com.au
e: [EMAIL PROTECTED]
----------------------------------------
