Is copy functionality supported by Hibernate?

Suppose I have User, Role tables and the relation between them is many-to-many. I want to copy a User with the method

copyUser(Long userId);

This method is supposed to create a new User record with all the attributes of the passed userId. That should also copy the associations in the other tables also. ie the new user should get all the roles that the source user from which new user has been created.

Hope I am clear..Is it directly supported by Hibernate?

Thanks,
SSSS.




Hibernate version:

Mapping documents:

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

Full stack trace of any exception that occurs:

Name and version of the database you are using:

The generated SQL (show_sql=true):

Debug level Hibernate log excerpt:

I don't know that it is supported directly by Hibernate (although I don't know that it isn't either). The way I tackled this problem was to override Object.clone() in my entities, and then create new entities from the existing ones just by calling myEntity.clone(). Very quick and easy, and it worked like a charm.

This is called the prototype pattern and is not really the persistence framework's responsibility.

don't know that it is supported directly by Hibernate (although I don't know that it isn't either). The way I tackled this problem was to override Object.clone() in my entities, and then create new entities from the existing ones just by calling myEntity.clone(). Very quick and easy, and it worked like a charm.

Can you plz give some sample on how to clone??

Thanks,
SSSS.

Can anyone provide the sample code for this clone()?

"beanlib" should solve this cloning problem for you: http://hansonchar.blogspot.com/2005/06/ ... rnate.html

It seems alot of person here wants this feature out of hibernate. I guess you guys want hibernate to clone an object by respecting cascade semantic defined in the mapping file of that entity?

Personally, for a parent-child relationship, I found that I want clone to copy only the parent object, sometimes I want it to copy all children also.

Copying of objects for me is cleary related to your business, not persistence. I personally find clone() a bad solution since you cannot pass it parameters.

I usually create a separate class with duplicateXXXX methods that answer my need and take all the parameters I want.

Some purists may find this solution not eleguant, but as soon as you coded those duplicate methods and they work, you realize you stop wasting time trying to be clean, you are more flexible than clone, and you finally work on your real important business ;)

In my case (and I have not fully learned everything I need to know about hibernate), I'm looking at the need to serialize my domain objects for transmission over RMI (through a session facade). This has a few implications:

- I cannot use lazy loading where I expect to transmit retrieved entities to the client
- I would prefer to avoid N+1 select situations, which is a very real problem when you turn off lazy loading (HQL queries have to be loaded with the expected data in mind to take advantage of table joins --> 'from Person p' becomes 'from Person p left join fetch p.addresses', and then create a new Set based on the returned list to remove duplicates)
- Different situations call for different parts of a retrieved object graph (i.e., I might only need the Person object, and not any of its associated addresses). Without lazy loading, this becomes much more difficult.

The best solution I can see is to allow lazy loading and then use something to create a detached transient copy of the retrieved results at some arbitrary depth. This would allow the performance benefits of lazy loading while still allowing for serializability. beanlib (below) looks promising, but at the same time, this is yet another dependency for my code. What would be great is if hibernate could support some sort of configurable copy utility -- perhaps with an associated section in the entity mapping for different... er... copy "plans".

What drives me mad about this is that I'm spending a lot of time figuring out these issues that are really communication and architecture-related, rather than focusing on the business model itself.

All that said, though, I'm still new to all of this, and there's probably a better solution out there that I just haven't run into yet.[/i]