You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-java@ibatis.apache.org by Tom Kunicki <tk...@usgs.gov> on 2010/05/20 05:17:47 UTC
ibatis-3-mapper.dtd question
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-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org