[Dev] Multiple choice

[Brett Wooldridge]

The installer would have to do it, but it has to do SOMETHING to select the
database and that is least intrusive option.

-Brett

On 10/18/07 2:02 PM, "Kartick Suriamoorthy" <ksuriamoorthy at alterpoint.com>
wrote:

> Wouldn't #3 require the installer to update the database.properties.
>  
> Or is the end user supposed to do that ?
>  
> -- Kartick
> 
> 
> From: dev-bounces at ziptie.org [mailto:dev-bounces at ziptie.org] On Behalf Of Ryan
> Kruse
> Sent: Thursday, October 18, 2007 1:54 PM
> To: dev at ziptie.org
> Subject: Re: [Dev] Multiple choice
> 
> #3 is fine with me.  #1 would be cool but probably too much trouble.
> 
> 
> 
> ----- Original Message -----
> From: dev-bounces at ziptie.org <dev-bounces at ziptie.org>
> To: ZipTie Development List <dev at ziptie.org>
> Sent: Thu Oct 18 11:54:41 2007
> Subject: [Dev] Multiple choice
> 
> Ok, so I¹ve added support for PostgreSQL in ZipTie (remarkably easy) but I am
> faced with a configuration issue.
> 
> There are three files that have to change to use PostgreSQL rather than Derby:
> 
> hibernate.cfg.xml:
> 
>         <property
> name="hibernate.dialect">org.hibernate.dialect.PostgreSQLDialect</property>
> quartz.properties:
> 
>          org.quartz.jobStore.driverDelegateClass =
> org.quartz.impl.jdbcjobstore.PostgreSQLDelegate
> c3p0.properties:
> 
>         <property name="driverClass">org.postgresql.Driver</property>
> <property 
> name="jdbcUrl">jdbc:postgresql://localhost/ziptie?user=postgres</property>
> 
> I see three options for development/deployment, maybe you see others.
> 
> 1) There is only one copy of each of these files, and the build AND installers
> know how to perform a substitution of these lines depending on the database
> selected (in build.properties or by the user during installation).  This adds
> complexity to the build and installers.
> 2) There are two copies of each of these files, for example
> c3p0.derby.properties and c3p0.pgsql.properties, and the build and installers
> know to copy the correct one to c3p0.properties (for example) depending on
> build.properties or user selection during installation.  This adds much less
> complexity to the build and installers, but means that edits to these files
> have to be performed twice (or more in the future) in order to keep them in
> sync.  Maybe not an issue given a very low frequency of change.
> 3) There are two copies of each of these files, for example
> c3p0.derby.properties and c3p0.pgsql.properties.  Both versions are deployed
> (or installed).  Based on some other property file (say database.properties),
> the server knows to which property file to load for the respective subsystem.
> For example, the server would load c3p0.pgsql.properties because
> database.properties contains a line that says ³database=pgsql².  This has
> minimal impact on the build and installers, but has the same requirement as
> (2) in that it requires changes to be replicated in multiple files..
> 
> I lean toward option 3.
> 
> What is your opinion or do is there another option I haven¹t considered?
> 
> -Brett
> 
> 
> 
> _______________________________________________
> Dev mailing list
> Dev at ziptie.org
> http://mailman.ziptie.org/listinfo/dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ziptie.org/pipermail/dev/attachments/20071018/2ecf1e77/attachment.html