db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <de...@segel.com>
Subject RE: Spawning Data on Multiple Directories
Date Thu, 04 May 2006 20:33:52 GMT
See my comments below

> -----Original Message-----
> From: Rodrigo Madera [mailto:rodrigo.madera@gmail.com]
> Sent: Thursday, May 04, 2006 3:09 PM
> To: Derby Discussion; msegel@segel.com
> Subject: Re: Spawning Data on Multiple Directories
> 
> Well, back to the original subject...
> 
> Yes, it's a real benefit to be able to use different _directories_ in
> the three only for certain users. In an enterprise where you have
> large RAIDs and special RAM disks this isn't attractive, but since
> Derby is not in that market space we can just leave that to
> PostgreSQL.
> 
[mjs] 
Well, don't sell your idea short.

How databases store their data on the physical disk is very important with
respect to size and performance.

Suppose you wanted to use Derby as part of a digital jukebox. You may want
to store the titles and artist information in one space, and then store the
actual MP3s on a different disk. 

> What I'm asking for is available in other DBMS, where you specify how
> many bytes to store in each directory. So you can make special
> combinations on this.
> 
> Indeed there is a select group of people to actually take advantage of
> such a feature.
> 
> Anyways, this feature is not going to be an impact in footprint. And
> yes, Derby needs an architectural improvement to allow plugins (or raw
> branches) for people who would like to add technical candy to it. It's
> nice to have a 2MB footprint, but in my case, I have one thousand
> times that in RAM, so I just don't care.
> 
[mjs] 
Uhm, well, actually it could. Take a step back and look at the larger
picture. You're now asking that Derby store certain tables in certain
spaces, and that these spaces can occur anywhere on disk. So now instead of
managing a single source of data, you now have to manage multiple sources.

> Of course, people who are playing with embedding databases in web
> pages will be concerned. In that case, turn the plugin off. People who
> upload the Derby engine in their wrist watch will like it to be small
> too... but then again, is Derby supposed to be functional? small? 100%
> Java?... Why not all of the above? Just make it modular.
> 
[mjs] 
Exactly.

But to make Derby modular, and to do it right would mean taking the time to
do a redesign of Derby. And that's the crux of it. Revamping the storage
infrastructure is a large project, larger than just a Jira issue.

You could say hey! Lets make authentication modular and possibly support
PAM. 
(Well you get the idea.) 

Since IBM and Sun have both the resources and a vested interest in Derby,
then it would make sense that they step up to the plate.

> I would love to contribute on the spirit of open source and make such
> an improvement, but I just don't have time to Get To Know The Code
> (TM) first. If there was a structured and accepted plugin engine I
> would definitely invest two weekends on this.
> 
[mjs] 
Two weekends? LOL...

Its actually a larger effort than that.
Of course before you volunteer, you really need to read the Apache licensing
and then you need to either sign off or get your employer's sign off on
indemnifying Apache for any potential litigation you may face on code that
you have provided.





Mime
View raw message