Is there any reason for the strict ordering of child elements for resultMap, 
resultMap/collection, and resultMap/association elements?

There current specification in the ibatis-3-mapper.dtd for the resultMap 
element looks like:

<!ELEMENT resultMap (constructor?,id*,result*,association*,collection*, 
discriminator?)>

For my work the order of calls to the mapped object is important and I would 
like to use:

<!ELEMENT resultMap 
(constructor?,id*,(result*|association*|collection*|discriminator?)*)>

to, as an example, support a structure something like

<mapper>
 <restultMap>
   <result />
   <association />
   <result />
   <collection />
 </resultsMap>
</mapper>

I have tested this against with my local build and it appears to work as 
desired which means the iBatis parsing can handle the DTD change (haven't 
noticed side effects *yet*).  Any thoughts on incorporation a change like this 
into future iBatis releases?

For background we are using iBatis 3.0 to directly map multiple row results 
sets to StAX events by using a singleton result object implementing the Map 
interface (from a custom ObjectFactory).  The map keys (property attribute of 
resultMap/result element) represent the XML element/attribute stack (along with 
some unflattening directives) and the values are the mapped columns.    So far 
this has allowed us to stream GB of results from a single request w/ minimal 
footprint. 

Thanks,

Tom Kunicki
Center for Integrated Data Analytics
U.S. Geological Survey
8505 Research Way
Middleton, WI  53562



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

Reply via email to