Hi,

Actually I only need a solution for = select; the other types are handled in the DAO. Let’s assume the following classes exist.

Class A = {

= id

= propertyA_1

= propertyA_2

= type

}

Class B extends A = {

= propertyB_1

= propertyB_2

= propertyB_3

}

The following resultmaps are = defined:

= </discriminator>

</resultMap>=

</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:

= </discriminator>

</resultMap>=

</resultMap>=

SELECT = type

FROM = A

WHERE id =3D = #value#

</select>

SELECT = *

FROM A, = B

WHERE A.id =3D = B.id

AND A.id =3D = #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 hope you understand from this = lengthy post what I would like to see added to iBATIS. 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 this is a common scenario, especially = in our application.

Let me know your = thoughts,

Niels

From: = Roberto R [mailto:roberto.rabe@gmail.com]
Sent: donderdag 16 juni = 2005 1:09
To: = user-java@ibatis.apache.org
Subject: Re: = Possibilities and/or impossibilities of subclassing

Hi. = Would it be possible for you to provide an example of what you'd like the DataMapper = to do (select, insert, update, and delete scenarios)?

Roberto

On 6/15/05, Niels Beekman = <niels@wis.nl> = wrote:

Yes, that is = also the answer I was looking for but nothing is mentioned
about _how_ to implement a table per subclass, and additionally, the
.NET-docs are updated again (v1.2.1) and now state the following:

* resultMap for each class
* resultMap with submaps for a class hierarchy
* resultMap with extended resultMaps for each subclass

Which does not even state the word 'table' anymore, and the
possibilities now listed are what I've figured out myself, but
unfortunately these are not sufficient for me.

Thanks for the answer,

Niels

-----Original Message-----
From: Ron Grabowski [mailto:rongrabowski@yahoo.com ]
Sent: woensdag 15 juni 2005 14:18
To: user-java@ibatis.apache.org
Subject: Re: Possibilities and/or impossibilities of subclassing

The next message in the thread had a list of three cases where the
discriminator might come in handy:

* table per class hierarchy
* table per subclass
* table per concrete class

That's the answer I was looking for. I believe both the .Net and = Java
version now have the same level of suppor for discriminators. Although =
I did noticed that the Java version specifies them like this:

<discriminator>
  <submap />
  <submap />
  <submap />
</discriminator>

While the .Net version does it like this:

<discriminator />
<submap />
<submap />
<submap />

Which leads me to believe the .Net version only allows for one
discriminator per resultMap ??? That's what I remember seeing at some =
point.

--- Niels Beekman <niels@wis.nl> wrote:

> Hi,
>
> Could you guys please clarify some of the possibilities and
> unpossibilities of iBATIS when it comes to subclassing?. What I =
> understand from the various documentation-fragments is that = iBATIS
> only
> supports discriminators when all columns are available in a = single
> resultset. How would this work when I have an ISA-design with let's =
> say
> 10 different subtables, this would result in enormous amounts = of
> data...
>
> Is there any documentation that I have missed somehow? I saw it = on
> the
> undocumented features-list, but maybe there is some after all. I =
> looked
> at the provided Documentation.xml but this is an example with = just
> one
> table, which is not I'm looking for. I even checked the .NET
> documentation too, the discriminator is mentioned there, but not in =
> the
> context of subtables (and I heard that iBATIS.NET has more features
> when
> it comes to subclassing).
>
> I hope you can shed some light on this, otherwise it requires some =
> workarounds on my end.
>
> Thanks for your time,
>
> Niels
>
> PS I tried to contact Ron for his solution
>
( http://www.mail-archive.com/ibatis-dev%40incubator.apache.org/msg01014.
> html) to this problem, as he said he was helped "off = list" but could
> not
> reach him.
>