Hi all,

I am looking for a bit of 'best practice' advice.

Currently I have the following mapped classes:




In my system generally 'Accounts' will be saved. However at later dates Accounts may need to be converted to ParentAccounts as they need extra responsibilities that Accounts do not include.

In terms of best practice whats the best way to upgrade a persistent stored item to a subclass?

Would you have to remove the previous item then re-add the account? Or is there another more efficient way of doing this?

Many thanks to all who read I appreciate your help.

Eggsy

Note that in the object-oriented world it is not possible for an object to change from one class to another. My first approach would be to try to redesign the code to get rid of the superclass/subclass relationship. Each account could for example have an AccountType.

If you can't do that and still want to use Hibernate cloning might be possible. Eg. load the Account object that you want to convert and create a new ParentAccount object and then copy properties to the new object. Then, delete the original and save the new object. This can be a problematic approach if you have lots of other objects with references to the original Account since you will also need to changes those to reference the new ParentAccount.

As a last resort you may bypass Hibernate for this and use SQL directly against the database. Just make sure that the Account you are trying to convert doesn't exist in memory, eg. in a Hibernate session or in the second-level cache.

Hi there,

Thank you for the reply.

I think I may have to go for the last resort option of performing a simply insert into the parent_account table.

I have also looked into specifying:


Because the parent_account table only has the id (currently) so that is all I need to be inserted but I'm using Hibernate from within a Spring container and cannot seem to make it use my defined SQLInsert function.

Hi there,

A bit more information on this.

After rethinking my ORM I have implemented the ParentAccount table to reproduce the composite design pattern so that potentially any account can be linked to other 'accounts'

So really I should save everything as a ParentAccount and set the parentAccountId only in linked child entities.

I guess I'm saying my design/storage process was incorrect which is why I was getting stuck when trying to implement my saving mechanisms.

Hi there,

A bit more information on this.

After rethinking my ORM I have implemented the ParentAccount table to reproduce the composite design pattern so that potentially any account can be linked to other 'accounts'

So really I should save everything as a ParentAccount and set the parentAccountId only in linked child entities.

I guess I'm saying my design/storage process was incorrect which is why I was getting stuck when trying to implement my saving mechanisms.