You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ibatis.apache.org by Clinton Begin <cl...@gmail.com> on 2008/08/13 07:50:13 UTC
iBATIS 3 XML SQL Map Decisions...
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
Re: iBATIS 3 XML SQL Map Decisions...
Posted by Clinton Begin <cl...@gmail.com>.
BTW: It's probably best to copy and paste that XML into an editor, it
doesn't read very well in an email window....
On Tue, Aug 12, 2008 at 11:50 PM, Clinton Begin <cl...@gmail.com>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
>
Re: iBATIS 3 XML SQL Map Decisions...
Posted by Brandon Goodin <br...@gmail.com>.
The only thing that i would note would be that the dynamic sql should
also contain an <choose/when/otherwise> or a <choose/if/else>.
B
On Wed, Aug 13, 2008 at 12:50 AM, Clinton Begin <cl...@gmail.com> 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
>
Re: iBATIS 3 XML SQL Map Decisions...
Posted by Jeff Butler <je...@gmail.com>.
Excellent! Now I can change ibator so that it can be used to generate
queries that return 50 billion rows and suck up all your network bandwidth!
(Just kidding)
Jeff Butler
On Fri, Aug 15, 2008 at 10:46 PM, Clinton Begin <cl...@gmail.com>wrote:
> The coolest thing... this test passes in iBATIS 3... no changes, it just
> worked.
>
> Clinton
>
>
> On Thu, Aug 14, 2008 at 12:44 PM, Jeff Butler <je...@gmail.com>wrote:
>
>> That's the general idea. I'm not sure of the merits of it or not. The
>> pro is that you could fill out a graph with one query. The con is that you
>> end up with a cross join and generate a ton of duplicate data coming back.
>>
>> The wierd thing is - sometimes this works, and sometimes it fails. I
>> haven't dug into it to see what the issue is, but here's a simple test case
>> that fails. All you need is iBATIS and HSQLDB to run it.
>>
>> Jeff Butler
>>
>>
>>
>>
>> On Thu, Aug 14, 2008 at 12:07 AM, Clinton Begin <cl...@gmail.com>wrote:
>>
>>> Couple of notes...
>>>
>>> * The top level call was for a list of categories (not just one).
>>>
>>> * I adapted this test from an existing test where categories had many
>>> products, which in turn had many items.
>>>
>>> So that would seem to be almost all of the possible cases... combinations
>>> of those should work, but I'd have to dream up quite a model to even come up
>>> with one. :-)
>>>
>>> Category
>>> - Items
>>> - Products
>>>
>>> ....or....
>>>
>>>
>>> Category
>>> - Products
>>> - Items
>>>
>>> Clinton
>>>
>>>
>>> On Wed, Aug 13, 2008 at 11:04 PM, Clinton Begin <clinton.begin@gmail.com
>>> > wrote:
>>>
>>>> I just wrote a little unit test for that. It totally works. Here's the
>>>> ResultMap to make sure we're talking about the same thing....
>>>>
>>>> <resultMap id="categoryResultMap" class="testdomain.Category"
>>>> groupBy="categoryId">
>>>> <result property="categoryId" column="catid"/>
>>>> <result property="name" column="catname"/>
>>>> <result property="description" column="catdescn"/>
>>>> * <result property="productList" resultMap="productResultMap"/>
>>>> <result property="itemList" resultMap="itemResultMap"/>*
>>>> </resultMap>
>>>>
>>>> <resultMap id="productResultMap" class="testdomain.Product" >
>>>> <result property="productId" column="productid"/>
>>>> <result property="categoryId" column="category"/>
>>>> <result property="name" column="prodname"/>
>>>> <result property="description" column="proddescn"/>
>>>> </resultMap>
>>>>
>>>> <resultMap id="itemResultMap" class="testdomain.Item">
>>>> <result property="itemId" column="itemid"/>
>>>> <result property="productId" column="productid"/>
>>>> <result property="listPrice" column="listprice"/>
>>>> <result property="unitCost" column="unitcost"/>
>>>> <result property="supplierId" column="supplier"/>
>>>> <result property="status" column="status"/>
>>>> <result property="attribute1" column="attr1"/>
>>>> <result property="quantity" column="qty"/>
>>>> </resultMap>
>>>>
>>>>
>>>>
>>>> Clinton
>>>>
>>>>
>>>> On Wed, Aug 13, 2008 at 10:17 PM, Larry Meadors <
>>>> larry.meadors@gmail.com> wrote:
>>>>
>>>>> On Wed, Aug 13, 2008 at 4:27 PM, Clinton Begin <
>>>>> clinton.begin@gmail.com> wrote:
>>>>> > 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?
>>>>>
>>>>> I *think* he's referring to something like where you have people that
>>>>> have cats and dogs.
>>>>>
>>>>> Say you have a PERSON table, a DOG table, and a CAT table.
>>>>>
>>>>> If DOG has a person_id and CAT has a person_id, and you join the three
>>>>> tables, you can't get a list of person objects each with the correct
>>>>> list of dog and cat objects.
>>>>>
>>>>> I've not really understood the desire for this one, because you can't
>>>>> really do that effectively with SQL, either - so instead of 1+N
>>>>> selects, you do one select that returns m*n*o records. So for 10
>>>>> people with 10 dogs and 10 cats, you get 1000 records instead of the
>>>>> 200 that 1+N selects get you.
>>>>>
>>>>> Rick has whined about that one for years. ;-)
>>>>>
>>>>> Larry
>>>>>
>>>>
>>>>
>>>
>>
>
Re: iBATIS 3 XML SQL Map Decisions...
Posted by Clinton Begin <cl...@gmail.com>.
The coolest thing... this test passes in iBATIS 3... no changes, it just
worked.
Clinton
On Thu, Aug 14, 2008 at 12:44 PM, Jeff Butler <je...@gmail.com> wrote:
> That's the general idea. I'm not sure of the merits of it or not. The pro
> is that you could fill out a graph with one query. The con is that you end
> up with a cross join and generate a ton of duplicate data coming back.
>
> The wierd thing is - sometimes this works, and sometimes it fails. I
> haven't dug into it to see what the issue is, but here's a simple test case
> that fails. All you need is iBATIS and HSQLDB to run it.
>
> Jeff Butler
>
>
>
>
> On Thu, Aug 14, 2008 at 12:07 AM, Clinton Begin <cl...@gmail.com>wrote:
>
>> Couple of notes...
>>
>> * The top level call was for a list of categories (not just one).
>>
>> * I adapted this test from an existing test where categories had many
>> products, which in turn had many items.
>>
>> So that would seem to be almost all of the possible cases... combinations
>> of those should work, but I'd have to dream up quite a model to even come up
>> with one. :-)
>>
>> Category
>> - Items
>> - Products
>>
>> ....or....
>>
>>
>> Category
>> - Products
>> - Items
>>
>> Clinton
>>
>>
>> On Wed, Aug 13, 2008 at 11:04 PM, Clinton Begin <cl...@gmail.com>wrote:
>>
>>> I just wrote a little unit test for that. It totally works. Here's the
>>> ResultMap to make sure we're talking about the same thing....
>>>
>>> <resultMap id="categoryResultMap" class="testdomain.Category"
>>> groupBy="categoryId">
>>> <result property="categoryId" column="catid"/>
>>> <result property="name" column="catname"/>
>>> <result property="description" column="catdescn"/>
>>> * <result property="productList" resultMap="productResultMap"/>
>>> <result property="itemList" resultMap="itemResultMap"/>*
>>> </resultMap>
>>>
>>> <resultMap id="productResultMap" class="testdomain.Product" >
>>> <result property="productId" column="productid"/>
>>> <result property="categoryId" column="category"/>
>>> <result property="name" column="prodname"/>
>>> <result property="description" column="proddescn"/>
>>> </resultMap>
>>>
>>> <resultMap id="itemResultMap" class="testdomain.Item">
>>> <result property="itemId" column="itemid"/>
>>> <result property="productId" column="productid"/>
>>> <result property="listPrice" column="listprice"/>
>>> <result property="unitCost" column="unitcost"/>
>>> <result property="supplierId" column="supplier"/>
>>> <result property="status" column="status"/>
>>> <result property="attribute1" column="attr1"/>
>>> <result property="quantity" column="qty"/>
>>> </resultMap>
>>>
>>>
>>>
>>> Clinton
>>>
>>>
>>> On Wed, Aug 13, 2008 at 10:17 PM, Larry Meadors <larry.meadors@gmail.com
>>> > wrote:
>>>
>>>> On Wed, Aug 13, 2008 at 4:27 PM, Clinton Begin <cl...@gmail.com>
>>>> wrote:
>>>> > 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?
>>>>
>>>> I *think* he's referring to something like where you have people that
>>>> have cats and dogs.
>>>>
>>>> Say you have a PERSON table, a DOG table, and a CAT table.
>>>>
>>>> If DOG has a person_id and CAT has a person_id, and you join the three
>>>> tables, you can't get a list of person objects each with the correct
>>>> list of dog and cat objects.
>>>>
>>>> I've not really understood the desire for this one, because you can't
>>>> really do that effectively with SQL, either - so instead of 1+N
>>>> selects, you do one select that returns m*n*o records. So for 10
>>>> people with 10 dogs and 10 cats, you get 1000 records instead of the
>>>> 200 that 1+N selects get you.
>>>>
>>>> Rick has whined about that one for years. ;-)
>>>>
>>>> Larry
>>>>
>>>
>>>
>>
>
Re: iBATIS 3 XML SQL Map Decisions...
Posted by Jeff Butler <je...@gmail.com>.
That's the general idea. I'm not sure of the merits of it or not. The pro
is that you could fill out a graph with one query. The con is that you end
up with a cross join and generate a ton of duplicate data coming back.
The wierd thing is - sometimes this works, and sometimes it fails. I
haven't dug into it to see what the issue is, but here's a simple test case
that fails. All you need is iBATIS and HSQLDB to run it.
Jeff Butler
On Thu, Aug 14, 2008 at 12:07 AM, Clinton Begin <cl...@gmail.com>wrote:
> Couple of notes...
>
> * The top level call was for a list of categories (not just one).
>
> * I adapted this test from an existing test where categories had many
> products, which in turn had many items.
>
> So that would seem to be almost all of the possible cases... combinations
> of those should work, but I'd have to dream up quite a model to even come up
> with one. :-)
>
> Category
> - Items
> - Products
>
> ....or....
>
>
> Category
> - Products
> - Items
>
> Clinton
>
>
> On Wed, Aug 13, 2008 at 11:04 PM, Clinton Begin <cl...@gmail.com>wrote:
>
>> I just wrote a little unit test for that. It totally works. Here's the
>> ResultMap to make sure we're talking about the same thing....
>>
>> <resultMap id="categoryResultMap" class="testdomain.Category"
>> groupBy="categoryId">
>> <result property="categoryId" column="catid"/>
>> <result property="name" column="catname"/>
>> <result property="description" column="catdescn"/>
>> * <result property="productList" resultMap="productResultMap"/>
>> <result property="itemList" resultMap="itemResultMap"/>*
>> </resultMap>
>>
>> <resultMap id="productResultMap" class="testdomain.Product" >
>> <result property="productId" column="productid"/>
>> <result property="categoryId" column="category"/>
>> <result property="name" column="prodname"/>
>> <result property="description" column="proddescn"/>
>> </resultMap>
>>
>> <resultMap id="itemResultMap" class="testdomain.Item">
>> <result property="itemId" column="itemid"/>
>> <result property="productId" column="productid"/>
>> <result property="listPrice" column="listprice"/>
>> <result property="unitCost" column="unitcost"/>
>> <result property="supplierId" column="supplier"/>
>> <result property="status" column="status"/>
>> <result property="attribute1" column="attr1"/>
>> <result property="quantity" column="qty"/>
>> </resultMap>
>>
>>
>>
>> Clinton
>>
>>
>> On Wed, Aug 13, 2008 at 10:17 PM, Larry Meadors <la...@gmail.com>wrote:
>>
>>> On Wed, Aug 13, 2008 at 4:27 PM, Clinton Begin <cl...@gmail.com>
>>> wrote:
>>> > 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?
>>>
>>> I *think* he's referring to something like where you have people that
>>> have cats and dogs.
>>>
>>> Say you have a PERSON table, a DOG table, and a CAT table.
>>>
>>> If DOG has a person_id and CAT has a person_id, and you join the three
>>> tables, you can't get a list of person objects each with the correct
>>> list of dog and cat objects.
>>>
>>> I've not really understood the desire for this one, because you can't
>>> really do that effectively with SQL, either - so instead of 1+N
>>> selects, you do one select that returns m*n*o records. So for 10
>>> people with 10 dogs and 10 cats, you get 1000 records instead of the
>>> 200 that 1+N selects get you.
>>>
>>> Rick has whined about that one for years. ;-)
>>>
>>> Larry
>>>
>>
>>
>
Re: iBATIS 3 XML SQL Map Decisions...
Posted by Clinton Begin <cl...@gmail.com>.
Couple of notes...
* The top level call was for a list of categories (not just one).
* I adapted this test from an existing test where categories had many
products, which in turn had many items.
So that would seem to be almost all of the possible cases... combinations of
those should work, but I'd have to dream up quite a model to even come up
with one. :-)
Category
- Items
- Products
....or....
Category
- Products
- Items
Clinton
On Wed, Aug 13, 2008 at 11:04 PM, Clinton Begin <cl...@gmail.com>wrote:
> I just wrote a little unit test for that. It totally works. Here's the
> ResultMap to make sure we're talking about the same thing....
>
> <resultMap id="categoryResultMap" class="testdomain.Category"
> groupBy="categoryId">
> <result property="categoryId" column="catid"/>
> <result property="name" column="catname"/>
> <result property="description" column="catdescn"/>
> * <result property="productList" resultMap="productResultMap"/>
> <result property="itemList" resultMap="itemResultMap"/>*
> </resultMap>
>
> <resultMap id="productResultMap" class="testdomain.Product" >
> <result property="productId" column="productid"/>
> <result property="categoryId" column="category"/>
> <result property="name" column="prodname"/>
> <result property="description" column="proddescn"/>
> </resultMap>
>
> <resultMap id="itemResultMap" class="testdomain.Item">
> <result property="itemId" column="itemid"/>
> <result property="productId" column="productid"/>
> <result property="listPrice" column="listprice"/>
> <result property="unitCost" column="unitcost"/>
> <result property="supplierId" column="supplier"/>
> <result property="status" column="status"/>
> <result property="attribute1" column="attr1"/>
> <result property="quantity" column="qty"/>
> </resultMap>
>
>
>
> Clinton
>
>
> On Wed, Aug 13, 2008 at 10:17 PM, Larry Meadors <la...@gmail.com>wrote:
>
>> On Wed, Aug 13, 2008 at 4:27 PM, Clinton Begin <cl...@gmail.com>
>> wrote:
>> > 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?
>>
>> I *think* he's referring to something like where you have people that
>> have cats and dogs.
>>
>> Say you have a PERSON table, a DOG table, and a CAT table.
>>
>> If DOG has a person_id and CAT has a person_id, and you join the three
>> tables, you can't get a list of person objects each with the correct
>> list of dog and cat objects.
>>
>> I've not really understood the desire for this one, because you can't
>> really do that effectively with SQL, either - so instead of 1+N
>> selects, you do one select that returns m*n*o records. So for 10
>> people with 10 dogs and 10 cats, you get 1000 records instead of the
>> 200 that 1+N selects get you.
>>
>> Rick has whined about that one for years. ;-)
>>
>> Larry
>>
>
>
Re: iBATIS 3 XML SQL Map Decisions...
Posted by Clinton Begin <cl...@gmail.com>.
I just wrote a little unit test for that. It totally works. Here's the
ResultMap to make sure we're talking about the same thing....
<resultMap id="categoryResultMap" class="testdomain.Category"
groupBy="categoryId">
<result property="categoryId" column="catid"/>
<result property="name" column="catname"/>
<result property="description" column="catdescn"/>
* <result property="productList" resultMap="productResultMap"/>
<result property="itemList" resultMap="itemResultMap"/>*
</resultMap>
<resultMap id="productResultMap" class="testdomain.Product" >
<result property="productId" column="productid"/>
<result property="categoryId" column="category"/>
<result property="name" column="prodname"/>
<result property="description" column="proddescn"/>
</resultMap>
<resultMap id="itemResultMap" class="testdomain.Item">
<result property="itemId" column="itemid"/>
<result property="productId" column="productid"/>
<result property="listPrice" column="listprice"/>
<result property="unitCost" column="unitcost"/>
<result property="supplierId" column="supplier"/>
<result property="status" column="status"/>
<result property="attribute1" column="attr1"/>
<result property="quantity" column="qty"/>
</resultMap>
Clinton
On Wed, Aug 13, 2008 at 10:17 PM, Larry Meadors <la...@gmail.com>wrote:
> On Wed, Aug 13, 2008 at 4:27 PM, Clinton Begin <cl...@gmail.com>
> wrote:
> > 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?
>
> I *think* he's referring to something like where you have people that
> have cats and dogs.
>
> Say you have a PERSON table, a DOG table, and a CAT table.
>
> If DOG has a person_id and CAT has a person_id, and you join the three
> tables, you can't get a list of person objects each with the correct
> list of dog and cat objects.
>
> I've not really understood the desire for this one, because you can't
> really do that effectively with SQL, either - so instead of 1+N
> selects, you do one select that returns m*n*o records. So for 10
> people with 10 dogs and 10 cats, you get 1000 records instead of the
> 200 that 1+N selects get you.
>
> Rick has whined about that one for years. ;-)
>
> Larry
>
Re: iBATIS 3 XML SQL Map Decisions...
Posted by Larry Meadors <la...@gmail.com>.
On Wed, Aug 13, 2008 at 4:27 PM, Clinton Begin <cl...@gmail.com> wrote:
> 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?
I *think* he's referring to something like where you have people that
have cats and dogs.
Say you have a PERSON table, a DOG table, and a CAT table.
If DOG has a person_id and CAT has a person_id, and you join the three
tables, you can't get a list of person objects each with the correct
list of dog and cat objects.
I've not really understood the desire for this one, because you can't
really do that effectively with SQL, either - so instead of 1+N
selects, you do one select that returns m*n*o records. So for 10
people with 10 dogs and 10 cats, you get 1000 records instead of the
200 that 1+N selects get you.
Rick has whined about that one for years. ;-)
Larry
Re: iBATIS 3 XML SQL Map Decisions...
Posted by Kai Grabfelder <no...@kinokai.de>.
+1 for changing the silentlyFailWhenNoResultClassOrResultMapPresent behaviour, I have to admit I stumpled
across this problem for several times ;-)
--- Original Nachricht ---
Absender: Larry Meadors
Datum: 16.08.2008 07:42
> Amen!
>
> ? = ambiguous
>
> One more thing: What about a
> shootFlamesOutTheBackOfTheComputerWhenNoResultClassOrResultMapPresent
> setting somewhere to offset the
> silentlyFailWhenNoResultClassOrResultMapPresent default. ;-)
>
> Maybe even have a default result mapping option - if all else fails,
> just dump the results into a map (and watch Vic clap with glee). :-D
>
> Larry
>
>
> On Fri, Aug 15, 2008 at 11:34 PM, Clinton Begin <cl...@gmail.com> wrote:
>> One thing I forgot to mention...
>>
>> With iB3 I don't think we should support question mark parameters at all
>> anymore. So even if you specify the <param> elements, they're no longer
>> ordinal. They are looked up from the #param placeholders in the statement.
>> That way SQL is more readable, and even the <param> elements need not be
>> repeated if used.
>>
>> Clinton
>>
>> On Fri, Aug 15, 2008 at 10:57 PM, Larry Meadors <la...@gmail.com>
>> wrote:
>>>
>>> On Wed, Aug 13, 2008 at 4:27 PM, Clinton Begin <cl...@gmail.com>
>>> wrote:
>>> > 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. :-)
>>>
>>> I like the *option* for param elements because it can help keep the sql
>>> cleaner.
>>>
>>> One of the biggest advantages of ibatis is that you can easily take
>>> the sql and just run it. IMO, adding a ton of inline parameter mapping
>>> info can make that harder.
>>>
>>> Larry
>>
>>
>
Re: iBATIS 3 XML SQL Map Decisions...
Posted by Larry Meadors <la...@gmail.com>.
Amen!
? = ambiguous
One more thing: What about a
shootFlamesOutTheBackOfTheComputerWhenNoResultClassOrResultMapPresent
setting somewhere to offset the
silentlyFailWhenNoResultClassOrResultMapPresent default. ;-)
Maybe even have a default result mapping option - if all else fails,
just dump the results into a map (and watch Vic clap with glee). :-D
Larry
On Fri, Aug 15, 2008 at 11:34 PM, Clinton Begin <cl...@gmail.com> wrote:
> One thing I forgot to mention...
>
> With iB3 I don't think we should support question mark parameters at all
> anymore. So even if you specify the <param> elements, they're no longer
> ordinal. They are looked up from the #param placeholders in the statement.
> That way SQL is more readable, and even the <param> elements need not be
> repeated if used.
>
> Clinton
>
> On Fri, Aug 15, 2008 at 10:57 PM, Larry Meadors <la...@gmail.com>
> wrote:
>>
>> On Wed, Aug 13, 2008 at 4:27 PM, Clinton Begin <cl...@gmail.com>
>> wrote:
>> > 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. :-)
>>
>> I like the *option* for param elements because it can help keep the sql
>> cleaner.
>>
>> One of the biggest advantages of ibatis is that you can easily take
>> the sql and just run it. IMO, adding a ton of inline parameter mapping
>> info can make that harder.
>>
>> Larry
>
>
Re: iBATIS 3 XML SQL Map Decisions...
Posted by Jeff Butler <je...@gmail.com>.
+1 definitely - no more question marks.
Jeff Butler
On Sat, Aug 16, 2008 at 12:34 AM, Clinton Begin <cl...@gmail.com>wrote:
> One thing I forgot to mention...
>
> With iB3 I don't think we should support question mark parameters at all
> anymore. So even if you specify the <param> elements, they're no longer
> ordinal. They are looked up from the #param placeholders in the statement.
> That way SQL is more readable, and even the <param> elements need not be
> repeated if used.
>
> Clinton
>
>
> On Fri, Aug 15, 2008 at 10:57 PM, Larry Meadors <la...@gmail.com>wrote:
>
>> On Wed, Aug 13, 2008 at 4:27 PM, Clinton Begin <cl...@gmail.com>
>> wrote:
>> > 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. :-)
>>
>> I like the *option* for param elements because it can help keep the sql
>> cleaner.
>>
>> One of the biggest advantages of ibatis is that you can easily take
>> the sql and just run it. IMO, adding a ton of inline parameter mapping
>> info can make that harder.
>>
>> Larry
>>
>
>
Re: iBATIS 3 XML SQL Map Decisions...
Posted by Clinton Begin <cl...@gmail.com>.
One thing I forgot to mention...
With iB3 I don't think we should support question mark parameters at all
anymore. So even if you specify the <param> elements, they're no longer
ordinal. They are looked up from the #param placeholders in the statement.
That way SQL is more readable, and even the <param> elements need not be
repeated if used.
Clinton
On Fri, Aug 15, 2008 at 10:57 PM, Larry Meadors <la...@gmail.com>wrote:
> On Wed, Aug 13, 2008 at 4:27 PM, Clinton Begin <cl...@gmail.com>
> wrote:
> > 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. :-)
>
> I like the *option* for param elements because it can help keep the sql
> cleaner.
>
> One of the biggest advantages of ibatis is that you can easily take
> the sql and just run it. IMO, adding a ton of inline parameter mapping
> info can make that harder.
>
> Larry
>
Re: iBATIS 3 XML SQL Map Decisions...
Posted by Larry Meadors <la...@gmail.com>.
On Wed, Aug 13, 2008 at 4:27 PM, Clinton Begin <cl...@gmail.com> wrote:
> 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. :-)
I like the *option* for param elements because it can help keep the sql cleaner.
One of the biggest advantages of ibatis is that you can easily take
the sql and just run it. IMO, adding a ton of inline parameter mapping
info can make that harder.
Larry
Re: iBATIS 3 XML SQL Map Decisions...
Posted by Clinton Begin <cl...@gmail.com>.
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 <je...@gmail.com> 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 <cl...@gmail.com>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
>>
>
>
Re: iBATIS 3 XML SQL Map Decisions...
Posted by Jeff Butler <je...@gmail.com>.
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 <cl...@gmail.com>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
>
Re: iBATIS 3 XML SQL Map Decisions...
Posted by Kai Grabfelder <no...@kinokai.de>.
besides the discussion about the structure of the xml I have one wish: Could you describe the xml with an xml
schema instead of a dtd? It's just more accurate to describe complex xmls with a schema instead of dtd.
Regards
Kai
--- Original Nachricht ---
Absender: Clinton Begin
Datum: 13.08.2008 07:50
> 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
>