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/[email protected]/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 {
id
propertyA_1
propertyA_2
type
}
Class B extends A {
propertyB_1
propertyB_2
propertyB_3
}
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"/>
</discriminator>
</resultMap>
<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”/>
</resultMap>
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”/>
</discriminator>
</resultMap>
<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”>
</resultMap>
<select id="A_get" parameterClass="int" resultMap="resultMap_A">
SELECT type
FROM A
WHERE id = #value#
</select>
<select id="B_get" parameterClass="int" resultMap="resultMap_B">
SELECT *
FROM A, B
WHERE A.id = B.id
AND A.id = #value#
</select>
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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
