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
<[EMAIL PROTECTED]> 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..
>

Reply via email to