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 Clinton Begin <cl...@gmail.com> on 2010/02/02 16:47:10 UTC
Re: regresssion (?) in beta 9: No automapping if some properties are
explicitly mapped
Sorry, this was a change. See the documentation for <settings> in the user
guide. Unfortunately I poorly advertised the change.
You can now configure the setting autoMappingBehavior="NONE|PARTIAL|FULL"
NONE and FULL are pretty self explanatory. FULL is how it worked in
previous betas. However, the new default is PARTIAL, which means that
automapping only happens on simple, flat queries. If you use associations
or collections, PARTIAL mode will not automap fields.
The primary reason was that I found when doing complex joins, it was hard to
tell where the value would end up, especially in cases where the column
matched multiple property names in parent and child objects. So I chose
PARTIAL to be a happy medium between simplicity and expressiveness. But if
you're confident that your unit testing will deal with any uncertainty, then
feel free to set it to FULL. Otherwise, I suggest sticking with PARTIAL.
There is also an obvious performance benefit to setting it to PARTIAL or
NONE.
Cheers,
Clinton
On Tue, Feb 2, 2010 at 7:26 AM, Stephen Friedrich <
stephen.friedrich@fortis-it.eu> wrote:
> I wonder if this was an intentional change:
>
> My mapping config looks like this:
>
>
>
> <resultMap id="partSetMap" type="PartSetDto">
>
> <id property="id" column="id"/>
>
> <collection property="parts" ofType=" PartDto">
>
> <result column="part_id" property="id" javaType="Long"/>
>
> <result column="serial_no" property="serialNo"
> javaType="String"/>
>
> <result column="is_reserved" property="isReserved"
> javaType="boolean"/>
>
> </collection>
>
> </resultMap>
>
>
>
> <select id="selectPage" resultMap="partSetMap">
>
> …
>
>
>
> PartSetDto has lots of other properties than “id”.
>
> In beta 8 those were automatically filled by naming convention.
>
> In beta 9 all other fields are empty.
>
>
>
Re: regresssion (?) in beta 9: No automapping if some properties are
explicitly mapped
Posted by Clinton Begin <cl...@gmail.com>.
The primary reason automapping is slower is that it does not cache the
mappings. Doing so creates concurrency challenges and also introduced the
notorious "remapResults" configuration switch in iBATIS 2.
I figure, if you want performance, map all of your results explicitly, and
turn of auto mapping (NONE). If you want simplicity, set it to PARTIAL. If
you have a pain fetish, set it to FULL.
Cheers,
Clinton
On Tue, Feb 2, 2010 at 1:28 PM, Stephen Friedrich <
stephen.friedrich@fortis-it.eu> wrote:
> Thanks for the quick response. Yes, I was looking for release notes
> somewhere close to the download link, but haven’t found any.
>
> Setting FULL did the trick.
>
>
>
> I had just started to evaluate performance anyway because first results on
> the integration server were not so great:
>
> A simple web service method (JAX-RS) that reads a thousand rows, then
> serializes that to JSON (no collections involved) takes two seconds.
>
> Now looking at some profiling results in YourKit I see that
> FastResulSetHandler.applyAutomaticMappings() alone takes up more than half
> of the total web service time:
>
>
>
> [I tried to send a screenshot here, but the mail was rejected due to
> suspected spam]
>
> 56% FastResultSetHandler.applyAutomaticMappings()
>
> 18% MetaObject.findProperty()
>
> 16% MetaClass.buildProperty()
>
> 13% Reflector.findPropertyName()
>
> 10% String.toUpperCase()
>
> …
>
>
>
> I already patched Reflector.findPropertyName() so that the calls to
> toUpperCase() are avoided, using an additional map:
>
> public String findPropertyName(String name) {
>
> // return caseInsensitivePropertyMap.get(name.toUpperCase());
>
> String propName = propertyMap.get(name);
>
> if (propName == null) {
>
> propName = caseInsensitivePropertyMap.get(name.toUpperCase());
>
> if (propName != null) {
>
> propertyMap.put(name, propName);
>
> }
>
> }
>
> return propName;
>
> }
>
> That is noticeably better - most of all on the real web server, which is a
> quite dated Sparc T2000 with horrible single-thread performance.
>
> However I feel that much better performance gains should be reachable on a
> higher abstraction level.
>
>
>
> Is there a conceptual reason why automatic mapping should be noticeably
> slower than explicit mapping?
>
> That should only make a difference for the first request, shoudn’t it?
>
>
>
> Stephen
>
>
>
> *Von:* Clinton Begin [mailto:clinton.begin@gmail.com]
> *Gesendet:* Dienstag, 2. Februar 2010 16:47
> *An:* user-java@ibatis.apache.org
> *Betreff:* Re: regresssion (?) in beta 9: No automapping if some
> properties are explicitly mapped
>
>
>
> Sorry, this was a change. See the documentation for <settings> in the user
> guide. Unfortunately I poorly advertised the change.
>
> You can now configure the setting autoMappingBehavior="NONE|PARTIAL|FULL"
>
> NONE and FULL are pretty self explanatory. FULL is how it worked in
> previous betas. However, the new default is PARTIAL, which means that
> automapping only happens on simple, flat queries. If you use associations
> or collections, PARTIAL mode will not automap fields.
>
> The primary reason was that I found when doing complex joins, it was hard
> to tell where the value would end up, especially in cases where the column
> matched multiple property names in parent and child objects. So I chose
> PARTIAL to be a happy medium between simplicity and expressiveness. But if
> you're confident that your unit testing will deal with any uncertainty, then
> feel free to set it to FULL. Otherwise, I suggest sticking with PARTIAL.
> There is also an obvious performance benefit to setting it to PARTIAL or
> NONE.
>
> Cheers,
> Clinton
>
> On Tue, Feb 2, 2010 at 7:26 AM, Stephen Friedrich <
> stephen.friedrich@fortis-it.eu> wrote:
>
> I wonder if this was an intentional change:
>
> My mapping config looks like this:
>
>
>
> <resultMap id="partSetMap" type="PartSetDto">
>
> <id property="id" column="id"/>
>
> <collection property="parts" ofType=" PartDto">
>
> <result column="part_id" property="id" javaType="Long"/>
>
> <result column="serial_no" property="serialNo"
> javaType="String"/>
>
> <result column="is_reserved" property="isReserved"
> javaType="boolean"/>
>
> </collection>
>
> </resultMap>
>
>
>
> <select id="selectPage" resultMap="partSetMap">
>
> …
>
>
>
> PartSetDto has lots of other properties than “id”.
>
> In beta 8 those were automatically filled by naming convention.
>
> In beta 9 all other fields are empty.
>
>
>
>
>
AW: regresssion (?) in beta 9: No automapping if some properties
are explicitly mapped
Posted by Stephen Friedrich <st...@fortis-it.eu>.
Thanks for the quick response. Yes, I was looking for release notes somewhere close to the download link, but haven't found any.
Setting FULL did the trick.
I had just started to evaluate performance anyway because first results on the integration server were not so great:
A simple web service method (JAX-RS) that reads a thousand rows, then serializes that to JSON (no collections involved) takes two seconds.
Now looking at some profiling results in YourKit I see that FastResulSetHandler.applyAutomaticMappings() alone takes up more than half of the total web service time:
[I tried to send a screenshot here, but the mail was rejected due to suspected spam]
56% FastResultSetHandler.applyAutomaticMappings()
18% MetaObject.findProperty()
16% MetaClass.buildProperty()
13% Reflector.findPropertyName()
10% String.toUpperCase()
...
I already patched Reflector.findPropertyName() so that the calls to toUpperCase() are avoided, using an additional map:
public String findPropertyName(String name) {
// return caseInsensitivePropertyMap.get(name.toUpperCase());
String propName = propertyMap.get(name);
if (propName == null) {
propName = caseInsensitivePropertyMap.get(name.toUpperCase());
if (propName != null) {
propertyMap.put(name, propName);
}
}
return propName;
}
That is noticeably better - most of all on the real web server, which is a quite dated Sparc T2000 with horrible single-thread performance.
However I feel that much better performance gains should be reachable on a higher abstraction level.
Is there a conceptual reason why automatic mapping should be noticeably slower than explicit mapping?
That should only make a difference for the first request, shoudn't it?
Stephen
Von: Clinton Begin [mailto:clinton.begin@gmail.com]
Gesendet: Dienstag, 2. Februar 2010 16:47
An: user-java@ibatis.apache.org
Betreff: Re: regresssion (?) in beta 9: No automapping if some properties are explicitly mapped
Sorry, this was a change. See the documentation for <settings> in the user guide. Unfortunately I poorly advertised the change.
You can now configure the setting autoMappingBehavior="NONE|PARTIAL|FULL"
NONE and FULL are pretty self explanatory. FULL is how it worked in previous betas. However, the new default is PARTIAL, which means that automapping only happens on simple, flat queries. If you use associations or collections, PARTIAL mode will not automap fields.
The primary reason was that I found when doing complex joins, it was hard to tell where the value would end up, especially in cases where the column matched multiple property names in parent and child objects. So I chose PARTIAL to be a happy medium between simplicity and expressiveness. But if you're confident that your unit testing will deal with any uncertainty, then feel free to set it to FULL. Otherwise, I suggest sticking with PARTIAL. There is also an obvious performance benefit to setting it to PARTIAL or NONE.
Cheers,
Clinton
On Tue, Feb 2, 2010 at 7:26 AM, Stephen Friedrich <st...@fortis-it.eu>> wrote:
I wonder if this was an intentional change:
My mapping config looks like this:
<resultMap id="partSetMap" type="PartSetDto">
<id property="id" column="id"/>
<collection property="parts" ofType=" PartDto">
<result column="part_id" property="id" javaType="Long"/>
<result column="serial_no" property="serialNo" javaType="String"/>
<result column="is_reserved" property="isReserved" javaType="boolean"/>
</collection>
</resultMap>
<select id="selectPage" resultMap="partSetMap">
...
PartSetDto has lots of other properties than "id".
In beta 8 those were automatically filled by naming convention.
In beta 9 all other fields are empty.