ibatis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niels Beekman (JIRA)" <ibatis-...@incubator.apache.org>
Subject [jira] Created: (IBATIS-169) Improvements to existing discriminator-feature
Date Tue, 12 Jul 2005 18:33:11 GMT
Improvements to existing discriminator-feature

         Key: IBATIS-169
         URL: http://issues.apache.org/jira/browse/IBATIS-169
     Project: iBatis for Java
        Type: Improvement
  Components: SQL Maps  
    Versions: 2.1.0    
    Reporter: Niels Beekman

Below is a modified version of a post to the mailinglist (http://www.mail-archive.com/user-java@ibatis.apache.org/msg00051.html)
so feel free to read that thread too.

Main reason to submit this improvement request is that the current support iBATIS offers for
class inheritence is not sufficient to conveniently handle more complex table-to-class mappings.
It currently only supports multiple classes persisted in one table. This request can be summarized
as follows: provide more flexibility for the table-to-class mapping.

Below is the example I posted to show how I would like iBATIS to handle selects.

Class A {

Class B extends A {

The following resultmaps are defined (OLD situation):

<resultMap id=”resultMap_A” class=”A”>
  <result property=”id” column=”id”/>
  <result property=”propertyA_1” column=”propertyA_1”/>
  <result property=”propertyA_2” column=”propertyA_2”/>
  <discriminator column=”type” javaType="int">
    <subMap value="1" resultMap="resultMap_B"/>

<resultMap id=”resultMap_B” class=”B” extends=”resultMap_A”>
  <result property=”propertyB_1” column=”propertyB_1”/>
  <result property=”propertyB_2” column=”propertyB_2”/>
  <result property=”propertyB_3” column=”propertyB_3”/>

What I would like to have is a way to do two things:

* writing a statement that joins A and B directly (when I know the type in advance)
* writing a statement that queries only A (when I do not know the type)

The first one is not a problem and works perfectly well, with and without a discriminator
defined. The second one is where my problem is, I want to execute a statement that specifies
class A as a result, iBATIS encounters the discriminator and checks which properties are required,
when not all properties are available in the resultset, it should execute a second statement
which fetches the additional properties required by the subclass (B in the example). This
statement could be specified as attribute in the subMap-tag.

Below is what I think the resulting sqlMap looks like (NEW situation):

<resultMap id=”resultMap_A” class=”A”>
  <result property=”id” column=”id”/>
  <result property=”propertyA_1” column=”propertyA_1”>
  <result property=”propertyA_2” column=”propertyA_2”>
  <discriminator column=”type” javaType="int">
    <subMap value="1" resultMap="resultMap_B" select=”B_get”/>

<resultMap id=”resultMap_B” class=”B” extends=”resultMap_A”>
  <result property=”propertyB_1” column=”propertyB_1”>
  <result property=”propertyB_2” column=”propertyB_2”>
  <result property=”propertyB_3” column=”propertyB_3”>

<select id="A_get" parameterClass="int" resultMap="resultMap_A">
  SELECT type
  WHERE id = #value#

<select id="B_get" parameterClass="int" resultMap="resultMap_B">
  WHERE A.id = B.id
  AND A.id = #value#

When I execute B_get, all values are already available, so no additional statement is required,
the query produces class B.
When I execute A_get, only the type is available, iBATIS detects which resultMap is required
using the discriminator, and checks whether all columns are available, this is not the case,
so B_get gets executed, now all columns are available, the query produces class B, when not
all columns are available, iBATIS first checks for a nested discriminator, otherwise throws
an error.

I know iBATIS is not an O/R-mapper, so I don’t expect behaviour ala JDO at all, but would
really like to see a solution for ISA, as I believe this is a common scenario in most applications.

Please share your thoughts on this.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message