Hey all,
I'd like to get some feedback on the things you like and dislike about the
current XML, and also show you some of the new XML. Without too much
talk... here's what I've started out with for the new iBATIS 3 mappings
Note that while this XML may look similarly verbose, realize that a lot of
it will be less necessary with 3.0. Overall, I hope the XML experience is
quite a bit simpler. The interface bindings will make a lot of the typing
unecessary.
<!-- Mappers can be interface bound now, it's two way, specified here, or in
the SqlMapConfig file, or both... possibly required here -->
<mapper type="com.domain.PersonMapper">
<!-- Cache configuration is dramatically simplified in iBATIS 3, and the
caching will be better too!
Here you see a simple setting that will configure all statements
contained in this class to use a cache template
called MyLRU, which will be defined in the SqlMapConfig.xml using
a syntax similar to the old one, but simpler and more consistent.
Default cache details can be overridden on each statement. -->
<defaultCache cacheType="MyLRU" cacheDomain="PersonMapper" />
<!-- What do you think about enclosing elements for resultMaps and
statements? -->
<resultMaps>
<resultMap id="" type="" extends="">
<!-- Yay, constructor mapping. -->
<constructor>
<!-- ids are not required, but will improve performance and caching
if provided. -->
<id column="" javaType="" jdbcType="" typeHandler=""/>
<result column="" javaType="" jdbcType="" typeHandler=""/>
</constructor>
<result property="" column="" javaType="" jdbcType="" typeHandler=""/>
<!-- the old 'groupBy' for join mapping is gone for good. this one
collection statement is all you need now. specifying ids will help with
performance here -->
<collection property="" column="" javaType="" select="" resultMap=""/>
<!-- good old discriminator, with a cleaner syntax and a default case
now -->
<discriminator column="" javaType="" jdbcType="">
<case value="" resultMap=""/>
<case value="" resultMap=""/>
<default value="" resultMap=""/>
</discriminator>
</resultMap>
</resultMaps>
<!-- again, thoughts on outer elements for statements? -->
<statements>
<!-- focusing on selects here... inserts, updates and deletes are less
interesting. -->
<!-- lots of attributes... too many maybe, but how else? -->
<!-- note the new parameter syntax. #param, #{param,attr=val} or
$inline, ${inline,attr=val}. -->
<select id="selectAllPeople" cacheType="" cacheDomain="" flushCache=""
parameterType="" resultType="" resultMap="">
select * from PERSON order by
${opts.order,javaType="",jdbcType="",typeHandler="",mode="",scale="",resultMap=""}
</select>
<select id="selectPersonInDept" cacheType="" cacheDomain=""
flushCache="" parameterType="" resultType="" resultMap="">
<!-- parameter maps are notoriously not reusable, and question marks
(?) suck. so no more question marks, always
use the name. To avoid having to retype the attributes in the
case of a parameter being reused, use a param element like these.
but otherwise, there's not much point in using anything other
than inline parameters -->
<param property="id" javaType="" jdbcType="" typeHandler="" mode=""
scale="" resultMap="" />
<param property="dept" javaType="" jdbcType="" typeHandler="" mode=""
scale="" resultMap="" />
select * from PERSON
where PERSON_ID = #param.id
<!-- dynamic SQL will be reduced to a few simple EL based tags to
replace the many specific tags in the past... -->
<!-- if(expr) foreach(x,expr) dynamic() propavail(name)
... common(prepend,open,conjuction,close) -->
<if expr="param.deptId != null">
and DEPT_ID =
#{param.deptId,javaType="",jdbcType="",typeHandler="",mode="",scale="",resultMap=""}
</if>
</select>
</statements>
</mapper>
Thoughts welcome.
Clinton
