left outer join and resultmaps

[dennis <de...@visi.com>]

Hi, I have question about how iBatis decides what query result value to 
load into a resultmap's property. Specically, the following query will 
produce a correctly constructed resultmap class with 'apples' usr_id set 
to a non-null value

select b*,c*,a*
from apple a, banana b
LEFT OUTER JOIN candy c on (c.usr_id = a.usr_id)
blah blah

when the result for the outer join does not return a  row  for  candy, 
while the  following query will  set  apples usr_id to null  when the 
same condition applies i.e. no row return for candy by the out join

select a.*, b.*, c*
from apple a, banana b
LEFT OUTER JOIN candy c on (c.usr_id=a.usr_id)

I suspect that iBatis is over writing the apple objects usr_id because 
the column names for the two tables are map to the same property name, 
and iBatis is just using the last seen value in the resultset to 
populate the value of apple regardless if the value actually came from a 
apple row.

Is this a bug?
I have tested this with iBatis 2.3.0.677 and 2.2.0.638 using postgresql 
driver 8.2-504.jdbc3.jar and jdk1.6.0, both iBatis versions behave the 
same.

Re: Interface PaginatedList

[Clinton Begin <cl...@gmail.com>]

PaginatedList is deprecated.  We suggest using the queryForList (id, param,
skip, max) method.  For paging you should only store the current page and
the page size in your presentation tier.

Clinton

On 3/5/07, Kulbhushan, Singh (IE10) <Ku...@honeywell.com> wrote:
>
> Hi,
>
> Why all methods are marked Deprecated in the javadoc of PaginatedList
> interface? Do we have methods to sort the page data?
>
> Thanks
> Kulbhushan
>

Interface PaginatedList

["Kulbhushan, Singh (IE10)" <Ku...@honeywell.com>]

Hi,

Why all methods are marked Deprecated in the javadoc of PaginatedList
interface? Do we have methods to sort the page data?

Thanks
Kulbhushan

Re: left outer join and resultmaps

[Larry Meadors <lm...@apache.org>]

Hm, I wouldn't call this a bug. It seems like the result set is sort
of random, based on the sql statement. If the results are not
consistent, the mapping won't be either.

I'd suggest 2 things:
 1) don't use "select *"...ever ;-)
 2) if you have 2 fields that have the same name, use an alias to make
them unique.

Larry


On 3/4/07, dennis <de...@visi.com> wrote:
> Hi, I have question about how iBatis decides what query result value to
> load into a resultmap's property. Specically, the following query will
> produce a correctly constructed resultmap class with 'apples' usr_id set
> to a non-null value
>
> select b*,c*,a*
> from apple a, banana b
> LEFT OUTER JOIN candy c on (c.usr_id = a.usr_id)
> blah blah
>
> when the result for the outer join does not return a  row  for  candy,
> while the  following query will  set  apples usr_id to null  when the
> same condition applies i.e. no row return for candy by the out join
>
> select a.*, b.*, c*
> from apple a, banana b
> LEFT OUTER JOIN candy c on (c.usr_id=a.usr_id)
>
> I suspect that iBatis is over writing the apple objects usr_id because
> the column names for the two tables are map to the same property name,
> and iBatis is just using the last seen value in the resultset to
> populate the value of apple regardless if the value actually came from a
> apple row.
>
> Is this a bug?
> I have tested this with iBatis 2.3.0.677 and 2.2.0.638 using postgresql
> driver 8.2-504.jdbc3.jar and jdk1.6.0, both iBatis versions behave the
> same.
>