AccountAccess is intended as an associative class, that is a materialization of an association between Client and Account. The meaning is: The Client has the right to manage the Account. The associative class is necessary, as the association "Client can manage Account" has an attribute which states, if the Client is the owner of the Account, or only a manager.
It was quickly implemented as a subclass of EntityBase<AccountAccess>. As an undesired consequence the associative class has an own ID. This implies, that the persistence would tolerate several links between a Client and an Account, even with contradictory values of the attribute isOwner. This is certainly not desirable.
A better solution would be to make the associative class have a primary key composed of the Client and the Account linked together. How to accomplish this with JPA has to be found out.
AccountAccess is intended as an associative class, that is a materialization of an association between
ClientandAccount. The meaning is: TheClienthas the right to manage theAccount. The associative class is necessary, as the association "Client can manage Account" has an attribute which states, if theClientis the owner of theAccount, or only a manager. It was quickly implemented as a subclass ofEntityBase<AccountAccess>. As an undesired consequence the associative class has an own ID. This implies, that the persistence would tolerate several links between aClientand anAccount, even with contradictory values of the attributeisOwner. This is certainly not desirable. A better solution would be to make the associative class have a primary key composed of theClientand theAccountlinked together. How to accomplish this with JPA has to be found out.