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.. >