ibator best strategy with multiple table formats

[A Bosetti <ab...@burrows.co.uk>]

Hi all

I am new to Ibatis and fairly new with java too so please bear it with me.

I have Eclipse 3.4, Java 1.6.17, Ibatis 2.3.4 and Ibator, all wired up with Spring 2.5.6.

I have an application that has an internal database and that also needs to connect to an external database.

The external database is provided by the customers and is made up of several tables (about 20) and it comes in two different formats (both formats are on Oracle), one that uses timestamps and the other one that uses a string representation of datetime. (Oracle 7 didnt have timestamps apparently)
There are only 3 fields in the whole database that are affected, everything else is exactly the same.

I have been given this version of the database with timestamps as a mock to test and develop my application before delivery,(which is the most common), but the application will have to run transparently on both versions of the database.
Obviously I don't have any control on the customers database but I wish to use Ibatis with Ibator as I find it very good.

What is a good strategy in this case?

I thought I could for instance treat the two databases as completely indipendent, generate two different versions of the ibator artifacts and inject the correct one to activate using spring, but it's a bit overkill to have to generate 20 different maps, 20 daos, 20 object models just because of 3 fields.

Then I thought it's better to modify the ibatismaps and inside the single generated map, have two versions of every statement that is affected by these fields (different inserts, selects etc), but is not very nice either, because then I need to manually modify the daos to call to correct statements.

Can you point me in the right direction? What is the most maintanable and elegant way to achieve this?

Thank you in advance 

Alessandro

Re: ibator best strategy with multiple table formats

[Alessandro <ab...@burrows.co.uk>]

Brilliant...thanks a million
Alex
Guy Rouillier wrote:
> On 2/11/2010 4:58 AM, A Bosetti wrote:
>> The external database is provided by the customers and is made up of
>> several tables (about 20) and it comes in two different formats (both
>> formats are on Oracle), one that uses timestamps and the other one that
>> uses a string representation of datetime. (Oracle 7 didnt have
>> timestamps apparently)
>
> Oracle 7??? That version of Oracle was released in 1992, and Oracle 
> ended support in 2000!  That was 10 years ago.  I'd suggest your 
> company not attempt to deal with databases 10 years past their 
> end-of-life.
>
> One idea is to obtain the Oracle version early in your program.  Pass 
> that version as a parameter to your SQL, and use an <if> condition to 
> do different things on the 3 columns that differ.  I imagine your 
> options are extremely limited for Oracle 7, which means that 
> "timestamp as a string" will have to be your least common 
> denominator.  So in the more recent version, do a to_char to convert 
> the timestamp into the same string format used by Oracle 7.  Then your 
> output column type is always string, and you can map it to your POJO 
> field.
>



---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org

Re: ibator best strategy with multiple table formats

[Guy Rouillier <gu...@burntmail.com>]

On 2/11/2010 4:58 AM, A Bosetti wrote:
> The external database is provided by the customers and is made up of
> several tables (about 20) and it comes in two different formats (both
> formats are on Oracle), one that uses timestamps and the other one that
> uses a string representation of datetime. (Oracle 7 didnt have
> timestamps apparently)

Oracle 7??? That version of Oracle was released in 1992, and Oracle 
ended support in 2000!  That was 10 years ago.  I'd suggest your company 
not attempt to deal with databases 10 years past their end-of-life.

One idea is to obtain the Oracle version early in your program.  Pass 
that version as a parameter to your SQL, and use an <if> condition to do 
different things on the 3 columns that differ.  I imagine your options 
are extremely limited for Oracle 7, which means that "timestamp as a 
string" will have to be your least common denominator.  So in the more 
recent version, do a to_char to convert the timestamp into the same 
string format used by Oracle 7.  Then your output column type is always 
string, and you can map it to your POJO field.

-- 
Guy Rouillier

---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org