hi,

i have the following classes

class group{
+ string name
+ user createdBy
}

class user{
+ int id;
+ string name;
}

class participant{
+ int roleId
+ int groupId
}

I have the following tables:

group
user
user_group


I have the following user/participant mapping:

<class name="user" table="[user]" lazy="false">

<id name="Id" column="id" type="Int32" unsaved-value="-1">
<generator class="identity"></generator>
</id>

<property name="Name" column="Name" type="String" />

<joined-subclass name="Participant "table="user_group" >
<key column="UserId"/>
<property name="GroupId" column="GroupId" type="Int32" />
<property name="Role" column="ParticipantRole"/>
</joined-subclass>

what I don't understand and even consider a bug is. why if I load a User NHibernate creates an outer join on user_group?!

I only whant one single user. The fields requested by the left outer join to "user_group" couldn be populated anyway.

bug or feature?

changing the fetching strategy (lazy=true) helped.

But I am still not happy with the behavior, since the query is performed for a type (Participant), which was not requested.

The "problem" is that in the joined-subclass inheritance strategy, an outer join must be performed so that NHibernate can know what the underlying type actually is. This behavior is by design. Suppose you are loading a User by id: just because you tell NH that you are looking for a User doesn't mean it isn't actually a Participant. The inheritance semantics imply that a Participant "is-a" User.

class User(){
...
}

class Participant : User(){
...
}


User user = session.Load<User>();
Participant participant = (Participant)user; //upcast fails


The upcast would fail anyway, so I don't see the point. Or do I miss sth.?

The upcast would not necessarily fail. When NH loads an object within an inheritance hierarchy from the DB, it loads it into its proper type. If it is saved as a Participant, it is loaded thereas; likewise User. In the example you cite, obviously a User reference can reference a Participant.

So, if you were doing a load from the database of a User without any foreknowledge of the subclass, you would want to "question" the object for its type before attempting such a cast:



NH has to load the object as it was saved, into it's proper class. In order to do this, it has to figure out what that is. For the joined-subclass strategy (for the time being, until mixed strategies are supported) this requires an outer join to every table in the hierarchy to determine the subclass. This is why the docs list the table-per-hierarchy strategy (which uses a discriminator) as much more performant.

I guess the question would be: if this is so unacceptable, what behavior do you imagine would be preferable?