db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rodrigo Madera" <rodrigo.mad...@gmail.com>
Subject Re: Spawning Data on Multiple Directories
Date Thu, 04 May 2006 20:09:23 GMT
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.

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.

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.

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.

Thanks for the input to all,
Rodrigo

On 5/4/06, derby@segel.com <derby@segel.com> wrote:
>
>
> > -----Original Message-----
> > From: Rodrigo Madera [mailto:rodrigo.madera@gmail.com]
> > Sent: Wednesday, May 03, 2006 1:28 PM
> > To: Derby Discussion; mikem_app@sbcglobal.net
> > Subject: Re: Spawning Data on Multiple Directories
> >
> > In that case, what about a proposal for the development team to allow
> > such one-database-multiple-directories architectural improvements?
> >
> [mjs]
> Well,
>
> Why stop at "multiple directories"?
>
> Not to get on a soap box, but what Rodrigo is asking for is the ability to
> create chunks or table spaces on either cooked or raw file system space.
> (Each chunk could be allocated on different disks/filesystems/etc...)
>
> The crux is that such a design will increase the footprint, and limit
> Derby's viability in certain niche markets. Heck, just the other day,
> someone was touting a url to someone who embedded Derby in to a web page...
>
> This goes back to the larger issue is the need to consider a look at
> redesigning Derby's framework to allow for options to be installed/removed
> at the time of deployment. (And there are some headaches even there too...)
>
>
> The point is that Derby is growing in popularity and certain larger issues
> than just quick fixes that can be addressed in a single JIRA issue need to
> be addressed.
>
> Of course, what do I know? ;-)
>
> I'm just a voice in cyber space. I no longer work for the blue pig nor do I
> work for Sun. Both heavy weights in Derby and both have their own agendas.
> What is being asked, will require the deep pockets of either or both
> companies. My bet is on Sun. IBM is still digesting the Informix vs DB2
> issue and adding Derby to the mix is not in their best interest. (At least
> on the surface. ;-)
>
> -Gumby
>
> > Depending on the OS to mount several devices (or directories) into a
> > parent one is not something trivial. And the gain in having such
> > flexibility is a sure winner.
> >
> > Rodrigo
> >
> > On 5/3/06, Mike Matrigali <mikem_app@sbcglobal.net> wrote:
> > > The data of a single database can only be in a single directory in
> > > the current derby implementation, spreading that data across multiple
> > > devices is left to the OS.  The log can be placed on
> > > a separate disk.
> > >
> [SNIP]
>
>
>

Mime
View raw message