ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Clinton Begin" <clinton.be...@gmail.com>
Subject Re: Questions on allowing users to switch to a different datasource
Date Fri, 01 Dec 2006 21:47:27 GMT
Hi Rick,

You can use:

Properties properties = new Properties();
properties.setProperty("DataSourceName");
SqlMapClientBuilder.buildSqlMapClient (reader, properties);

Then in the SqlMapConfig.xml file:

<property name="JDBC.ConnectionURL" value="jdbc:hsqldb:${DataSourceName}"/>

Where this breaks down is when you have a completely different setup for
dev, test and prod....like dev and test use SimpleDataSource and prod uses
JNDI....that gets a bit annoying.  But you can use XML includes or some
build task to substitute the entire config section into the
SqlMapConfig.xmlfile.

Clinton

On 12/1/06, Rick Reumann <rickcr@gmail.com> wrote:
>
> I'm a slacker and not using Spring to create any iBATIS daos.
>
> In my existing application I'd like to allow the user to be able to to
> switch between going against a dev or test/qa db.
>
> What I was thinking of doing is...
>
> 1) app start up (or lazy on first base dao call), I'd populate two
> SqlMapClient objects (one dev, one test). This creates a bit of problem,
> though, since I've been building the SqlMapClient object as
> SqlMapClientBuilder.buildSqlMapClient (reader); -- but the reader reads
> from the sqlMapConfig file which points to my datasource. I don't mind
> duplicating that config file and have each point to the datasource I want,
> but it seems there must be a better way to set it up since each file would
> end up with all the duplicate sql map definitions, etc.
>
> 2) Users then get their own dao in Session which has a handle to either
> the dev or qa SqlMapClient. If the user switches to another datasource
> (picks from a drop down in the front end), the sqlMapClient in their dao
> instance will point to the new one they chose.
>
> I haven't figured out how I want to handle the service layer, but that
> part won't be bad.
>
> I'm more concerned at this point as the approaches others have taken.
>
> Thanks.
>

Mime
View raw message