john.yesberg wrote:
If Marker and Commissioner are both separate subclasses of User, then you can't expect Hibernate to successfully cope with an object that is both. It really is a system than maps single-inheritance classes to tables.
You're right. When a User is a Commissioner *and* a Marker, and I load that User, an instance of Commissioner is created (because Commissioner joined-subclass is first in the hbm), not a Marker. But when I load a Commissioner or a Marker (instead of a User), it instantiates the good class correctly.
john.yesberg wrote:
(I understand that your class hierarchy doesn't allow you to have an object that is both a Marker and Commissioner.)
Actually, a Marker is a Marker, a Commissioner is a Commissioner, that's for sure. And that can make sense when I know that when I am working with Markers, I am not working with Commissioners. To know what the User is, I have UserRoles for that. But I make a distinction between the roles and the actual physical state of the user -- the role will control the access to the system functions, and the table row in commissioner will give the information about the "real" commissionner, which could give commissioner's access to a Marker by giving him the commissioner role...
Well, anyway, that's not the topic. :)
john.yesberg wrote:
You may be able to modify your domain model. Instead of arguing that some users are markers, and some are commissioners, and some are both, you could say that a user may be associated with a certain marker role, and may be associated with a certain commissioner role. I'd use a nullable ManyToOne relationship in each case.
I don't think there'll be any loss in efficiency, and it will possibly be more maintainable code (ie. simpler to understand).
How does that sound to you?
I didn't want to do that from the beginning, but I think that's the way I will have to make it work. I wanted to take advantage of the inheritance, the OO of the model... that's too bad.
I will have one-to-one relationships between User and Commissioner, User and Marker... Commissioner and Marker are not only roles, but contain also precious information that I didn't include in my previous posts.
Thank you John for your thoughts. More ideas are more than welcome! :)
Kexkey