Migration problem..

[Fabio Insaccanebbia <fi...@gmail.com>]

Hi,
I'm trying to make a switch from a custom "query manager" to iBatis SQLMaps.
The custom "query manager" has a catalog of query identified with a name 
so that the "catalog conversion" could be made without too much effort.

Unfortunately the "query manager" was not intended to be an O/R Mapping 
Framework.. every query accepted an array of object and returned a Rowset.

What I'd like to is to substitute our "query manager" with iBatis and 
then, one function a time, introduce the Dao layer.

The "big" hurdle here is the Rowset..
Can anybody suggest me a way to make an easier migration?
(it would have been easier if we had used a List of Maps instead of a 
Rowset)

My option:
(1) Rewrite all the application in one step to introduce the Dao and 
iBatis (too much effort)
(2) Add iBatis in addition to the current "query manager" and switch all 
the functions one after the other. At the end, remove the "query 
manager" (the problem here is the maintenance of two different 
frameworks and query catalogs)
(3) Make iBatis return a List of Maps and use the resulting data to 
emulate a RowSet (added data elaboration... impact performace?)
(4) Make a "custom modification" to expose the ResultSet from iBatis. 
(doesn't sound easy... and while it would help me a lot it is an 
horrible solution in general)
(5) ....

Any suggestion?

Fabio

P.S.: I know the (4) is blasphemous, since it goes against the spirit of 
O/R Mapping.. I list it here only because it could help introducing O/R 
Mapping without having to introduce it at once..

Re: Migration problem..

[Larry Meadors <la...@gmail.com>]

One solution: implement a List backed version of RowSet - RowSet (and
ResultSet) can be easily stretched over a List of Maps or Beans.

Larry

On Mon, 24 Jan 2005 17:59:54 +0100, Fabio Insaccanebbia
<fi...@gmail.com> wrote:
> Hi,
> I'm trying to make a switch from a custom "query manager" to iBatis SQLMaps.
> The custom "query manager" has a catalog of query identified with a name
> so that the "catalog conversion" could be made without too much effort.
> 
> Unfortunately the "query manager" was not intended to be an O/R Mapping
> Framework.. every query accepted an array of object and returned a Rowset.
> 
> What I'd like to is to substitute our "query manager" with iBatis and
> then, one function a time, introduce the Dao layer.
> 
> The "big" hurdle here is the Rowset..
> Can anybody suggest me a way to make an easier migration?
> (it would have been easier if we had used a List of Maps instead of a
> Rowset)
> 
> My option:
> (1) Rewrite all the application in one step to introduce the Dao and
> iBatis (too much effort)
> (2) Add iBatis in addition to the current "query manager" and switch all
> the functions one after the other. At the end, remove the "query
> manager" (the problem here is the maintenance of two different
> frameworks and query catalogs)
> (3) Make iBatis return a List of Maps and use the resulting data to
> emulate a RowSet (added data elaboration... impact performace?)
> (4) Make a "custom modification" to expose the ResultSet from iBatis.
> (doesn't sound easy... and while it would help me a lot it is an
> horrible solution in general)
> (5) ....
> 
> Any suggestion?
> 
> Fabio
> 
> P.S.: I know the (4) is blasphemous, since it goes against the spirit of
> O/R Mapping.. I list it here only because it could help introducing O/R
> Mapping without having to introduce it at once..
>