Some comments:
1. Looks good!
2. Enclosing elements seems OK to me
3. +1 on killing parameter maps. I strongly dislike declared parameter maps
and think that they are constantly misused/misunderstood. I'm not clear
what the benefit of the <param> element is - why not force inline parameters
100% of the time?
4. I like the idea of EL type dynamic tags with a fairly open expression
language.
5. What have you thought about for groupBy? I think the current
implementation is a little confusing. Also, do you envision being able to
handle multiple independant lists? I've always wanted to implement this
myself, but I get very lost in the current result set handing.
Jeff Butler
On Wed, Aug 13, 2008 at 12:50 AM, Clinton Begin <[EMAIL PROTECTED]>wrote:
> 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
>
