Re: [jira] Created: (DERBY-646) In-memory backend storage support

[Francois Orsini]

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...

--francois

On 11/3/05, Øystein Grøvlen <[EMAIL PROTECTED]> wrote:

>>>>> "SF" == Stephen Fitch <[EMAIL PROTECTED]> 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