Hello,

What I have in my application is a class, say Account, and a subclassed class AdminAccount. Sometimes I need to promote an Account to an AdminAccount. So I wanted to know if there is an idiomatic or good practice way to achieve that in Hibernate. The only solution I have found so far is to delete the old object and create a new one of the new class. I am not very happy with that as it seems ugly, and in particular, it forces me to copy all the elements of the collection of the Account.

So, is there a magic cast in Hibernate? :) Or is this the only way?

Note the following code below is Groovy code, not Java, but the problem is the same in Java.

Hibernate version: 3.2.6 (latest)

Code between sessionFactory.openSession() and session.close():

def hibernateSession = sessionFactory.getCurrentSession()

Account user = (Account) hibernateSession.load(Account.class, myId);

AdminAccount account = new AdminAccount(user)

// We have to copy the collection, this is ugly

user.articles.each()
{
account.addToArticles(it)
}

hibernateSession.delete(user)
hibernateSession.flush()

hibernateSession.save(account)



Name and version of the database you are using:

MySQL 5.0.40+

As I did not receive yet any reply ot this post, attempting to bump...

Use inheritance mapping. This is real magic of Hibernate ;). More clues: http://www.hibernate.org/hib_docs/reference/en/html/inheritance.html

I am already using inheritance mapping, thus both Account and AdminAccount are mapped using Hibernate (one table per class hierarchy).

But I don't see how this solve my problem or help me in any way, did you understand what I am trying to achieve?

Well, I do not now of a Hibernate "magic" like this either, but there is a rather simple solution that is baout model design: even if you did not use persistence for the project, you would have to create an AdminAccount to perform the above operation and copy the article collection. This would also be a bit tedious coding, although less "preformance painful".

So why not encapsulate all fields that are common for a user, not matter what type of account the user has (as clearly the articles collection is here) in another clss called User, and a User can have an Account field, that can be either an AdminAccount or not? This way you will be creating an AdminAccount only with those fields that should indeed be reassigned.

I know this was not the answer you were hoping for but I hope this is a direction worth thinking of....

Thanks for the post. Clearly I have already been thinking about your solution. Especially given the problems I am now facing, whereas what I want to do is probably a common operation...

I would still like however to conserve a OO programming approach, so still would like to subclass. Plus, I have now spent at least 10 hours on this problem, so I do want to find a solution in the end :)

I'lll think I start a new thread related to the various things that I have tried (and so far all have actually failed).