Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Date: Thu, 03 Nov 2005 17:06:40 -0400
From: Stephen Fitch <051933f@acadiau.ca>
Subject: Re: [jira] Created: (DERBY-646) In-memory backend storage support
In-reply-to: <7921d3e40511030705n74cb34a3ve9a24e4260724481@mail.gmail.com>
To: derby-dev@db.apache.org
Message-id: <436A7BE0.1040907@acadiau.ca>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 8BIT
References: <1527660289.1130261635642.JavaMail.jira@ajax.apache.org>
 <43639A55.1020208@sbcglobal.net> <43640D75.907@acadiau.ca>
 <x1of4q6xon0e.fsf@clustra.norway.sun.com> <43662830.9040306@acadiau.ca>
 <x1ofll08y5t2.fsf@atum11.norway.sun.com> <4367696C.2060209@acadiau.ca>
 <x1ofwtjrv4na.fsf@atum11.norway.sun.com> <43691BDA.1090604@acadiau.ca>
 <x1ofacglu9z7.fsf@atum11.norway.sun.com>
 <7921d3e40511030705n74cb34a3ve9a24e4260724481@mail.gmail.com>
User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716)

I agree with Francois. Booting a database with a special client seems 
needlessly complicated when it can be externally specified outside of an 
application.

I understand where you're coming from now though �ystein.

This all started because I was trying to get alternate StorageFactorys 
working in the network client/server setup.  I was looking at it from 
the perspective that anyone could be connected and doing anything 
anywhere on the network server at anytime. So, to just assume what 
StorageFactory is already active is the one you want when you dont 
specify one may cause unpredictable results in this case.


Stephen


Francois Orsini wrote:
> 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* <Oystein.Grovlen@sun.com 
> <mailto:Oystein.Grovlen@sun.com>> wrote:
> 
>      >>>>> "SF" == Stephen Fitch <051933f@acadiau.ca
>     <mailto: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
> 
>