Just a thought, you could try using the resultMap attribute of the
result tag. Its implementation may be better for 0 or 1 cardinality.
<resultMaps>
<resultMap id="CityResult" class="City">
<result property="Id" column="CITY_ID"/>
<result property="Name" column="city_name" />
<result property="IsPolluted" column="city_is_polluted" />
</resultMap>
<resultMap id="PersonResult" class="Person">
<!-- may need namespace in resultMap attribute below -->
<result property="City" resultMap="CityResult" />
<!-- others -->
</resultMap>
</resultMaps>
This is just a guess, but would only take a minute to try (your SQL
should not change at all). This approach is normally used with the
groupBy attribute to deal with N+1 avoidance, but there's no reason it
shouldn't work without it, and may actually solve the problem.
Here's hoping it doesn't expect the City property to be a collection.... ;-)
Cheers,
Clinton
On 8/8/07, Dustin Aleksiuk <[EMAIL PROTECTED]> wrote:
>
>
> Hi folks,
>
> The scenario (the example is just an example since our real objects have lots
> of extra that gets in the way):
>
> 2 classes. Both complex types, one has a field typed as the other. ie.
>
> public class Person
> {
> private City city;
>
> <property for city here...>
> }
>
> To avoid the hit of a subselect in the iBatis map, we do an outer join on
> Person and City. So our map looks like this:
>
> <resultMaps>
> <resultMap id="Result" class="Person">
>
> <result property="City.Id" column="CITY_ID"/>
> <result property="City.Name" column="city_name" />
> <result property="City.IsPolluted" column="city_is_polluted" />
>
> <!-- ... other stuff removed -->
>
> </resultMap>
> </resultMaps>
>
> The question: Is there some kind of handler I can write so that if the
> city_id column is null on the person table I can end up with a null city
> field on my Person object? Or can we only handle this by using subselects?
>
> I tried using a type handler, but when it returns null, iBatis kindly creates
> an instance of City so it can assign null to Id, Name and IsPolluted.
>
> Much thanks,
> Dustin Aleksiuk
