>Yea, ok, then you're pretty much stuck with the burden of cleaning up your object graph by hand and removing the primary keys. The JPA isn't going to do that for you.
Which is imho a big miss from the jpa spec. They have everything to do that, it just misses a cleanup() method with some copy/paste from merge(). (okay, i might simplify a bit there....)
Anyone willing to do a bit more than the CRUD tasks is forced to adapt its architecture. One can no longer use POJO.
Being able to do that operation not only gives the possibility to duplicate entries -which is something imho needed by lots of applications- but also to transport data, which is also important.
>One, you could simply write several "reset" methods in all of your domain
Yes, i think i'll finally resort to write some kind of visitor pattern thingy so that i can nullify ids. But i can tell you i'll be doing that with a tear drop. This is really something that should be done by jpa, not us.
>Another is to implement the Externalizable interface on all of your objects...
But that would add lots of burden to write all that code, increase possibilities of problems due to maintenance, ... I certainly do not want that.
Your idea about serializing could nevertheless bring something interesting. If i can parse the buffer and set to null all fields having an @ID annotation before unmarshalling, that could do the trick. That would be a diiiiiiiiiiiiiiiirty trick but would at least not add burden to my code. I'll look into that first.
Mhh, thinking more, maybe i'll have more luck serializing to xml, parsing the data, removing id tags and unmarshalling. Less dirty.
Is there any place where the reset functionnality can be added as a proposal for next jpa spec? I wonder if it would be needed to be a jcp member for that....
[Message sent by forum member 'pepe' (pepe)]
http://forums.java.net/jive/thread.jspa?messageID=252887