I'm trying to model the following 1-to-many relationship:




AccountLog's accountID refers to UserAccount's accountID.

At first, I thought of modeling this as a parent-child relationship (ala the Hibernate user guide example), since I want UserAccount to manage the lifecycle of AccountLogs (removing a UserAccount should remove all logs referencing that account).

The thing, though, is that I don't want to have an accountLogs property in UserAccount. In fact, I don't want UserAccount to have any knowledge at all about AccountLogs.

Is there a way to establish this "parent/child"-kind of relationship without having to declare a property for AccountLogs in UserAccount? (I'm relatively new to Hibernate, so I apologize if this question was already discussed.)

The fact that your saying you want to have UserAccount manage the lifecycle of a AccountLog and yet you want UserAccount to not have any reference to AccountLog is the problem (as you are aware, I'm just restating).

Because you wouldnt have any collection property to AccountLogs in your UserAccount means you couldnt do any cascade-delete properties in your mapping file.


One way you could do this is to go ahead and map this as a bidrectional association but be very restrictive on access permissions to your accountLogs collection in your UserAccount.



Joe

If you don't want to want UserAccount to have any knowledge, then just code it that way. Hibernate will allow you to write queries and mappings the other way around.

However, if AccountLog is not the main domain object that users will try and query out of the user database, you'll have to load the UserAccount object first and then query for AccountLog using UserAccount.getId(). This isn't really that bad, but it's more verbose than it needs to be because of 2 queries instead of one. You'll also lose out on fetching (something like from UserAccount useraccount left join fetch userAccount.accountLogs for example). If you need to get all of the account logs most of the time, you're probably better off letting UserAccount know about it them.

I would model the objects per the requirements of the app. There is nothing wrong with either approach, but make sure it's natural for the requirements. If user's aren't looking up UserAccounts by the AccountLog, then hiding AccountLog from UserAccount doesn't make sense. AccountLog should be encapsulated inside UserAccount and UserAccount should be the aggregate.