db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francois Orsini <francois.ors...@gmail.com>
Subject Re: [jira] Created: (DERBY-646) In-memory backend storage support
Date Thu, 03 Nov 2005 15:05:07 GMT
I agree with Oystein on the principle but at the same time we need to be
consistent in the way we specify properties for a database before it is
booted. (booting properties) - like when booting an encrypted database you
would have to specify the 'bootPassword' property in the jdbc connection
URL. If an application is well-written, it should *not* hardcode the
connection URL but make it either a java property or have it defined as part
of a Datasource so that the application does not get changed when the
connection URL does.

If we have a separate client to boot a database, IMHO it is going to cause
confusion and we would end-up having 2 different ways of booting a database
which I don't think it's right.

Just my 0.02 cents...


On 11/3/05, Øystein Grøvlen <Oystein.Grovlen@sun.com> wrote:
> >>>>> "SF" == Stephen Fitch <051933f@acadiau.ca> writes:
> SF> Øystein Grøvlen wrote:
> >> (Connecting without specifying StorageFactory
> >> should just use whatever has been booted.)
> >>
> SF> 3. If a StorageFactory exists and a connection is attempted WITHOUT
> SF> specifying a StorageFactory, and the StorageFactory in use is NOT the
> SF> default (DirStorageFactory), throw an Exception. I think this would
> SF> be preferred behavior because if you connected with just
> SF> jdbc:derby:dbname you would assume it would be using the default
> SF> StorageFactory.
> I do not agree on this. I would like to separate the concerns so that
> an application does not need to be rewritten to work with different
> storage factories. A special client can be used to boot the database
> with the desired StorageFactory.
> --
> Øystein

View raw message