emmettwalsh wrote:
and if im right your answer would be something like - the discriminating column is purely for creating the right objects with the extra behaviour needed. So if in fact a user did have an admin and a producer role, then the discriminating column would just have a value of 'PRODUCER', and the object created would be a Resource (as this has needs some extra behaviour at times). The user would still hold its associated list of roles (i.e. admin and producer), and work as a normal user object, but has the extra behavior needed for a producer.
That's about right. Again, all this really is based on the fact that you want a single method on the User object (or an object that extends that class) to return different information based on the "type" of the user, and that you want to restrict the range of the values for the two types of relationship from your ScheduleEntry to only users of the appropriate "type".
If you don't mind having only one User type, you can set the two ScheduleEntry relationships to just be to generic "User" objects, you could use a single class. (This would mean there's no automagic check that all appointments are a consumer meeting with a producer.) You could always have hibernate automagically set two different attributes on User for the two ends of the relationship, and have the getScheduleEntry method simply return the union of those two lists.
If I use SINGLE table inheritance with the appfuse User class as the base class, how do I specify the users role name as the discriminating column, when the user can have a few roles. Or do I need to have a new column in the user table ?
The discriminator column must be in the table corresponding to the class. -Dale --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
