3. <param element> : The thought here is to allow for specifying the
options (e.g. javaType="") outside of the SQL statement and to avoid
duplication if the same property is used more than once. But maybe it's too
much for such a rare case? But still, some people may prefer to keep the
param details out of the SQL itself. Hmmm... anyone else have an opinion
here? I'd love to only use inline params myself. But it's almost too easy
to agree in this case. :-)
4. groupBy is gone completely. The <collection> element combined with the
ID element now work together to achieve this. I agree the old
implementation was annoying. What do you mean by multiple independent
lists? Does that not work now?
Cheers,
Clinton
On Wed, Aug 13, 2008 at 2:51 PM, Jeff Butler <[EMAIL PROTECTED]> wrote:
> 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
>>
>
>
