I have a curious problem, which will enrich my knowledge about persistence.
I have two classes B and C, which inherit from a base abstract class A.
I want to be able to create both an instance of B or an instance of C (one of them, not both) in the same user case, and since I want to edit some of the inherited fields, need to manage a single object of class A, and then depending on an alternator control, switch 'a' to be 'b' or 'c', depending the case.
To facilitate this I programmed a method to populate all shared fields (belonging to A) between 'b' and 'c' when they alternate in the user case.
The problem arises when saving, then by default, an object of type B is created. When this is the case there's no problem, but when switching to the C type, and try to save I get a TransientObjectException.
@Relationship members in type A have all CascadeType.MERGE and PERSIST marked. I think I cannot simply get a collection from 'b' and put it into 'c'. There might be some incongruence regarding persistence. I believe some additional processing must be done but to be honest, don't know what to start with.
I'm not sure if I understand this, but, stripped of the ORM considerations, it sounds like you have a parent class X, and two derived classes Y and Z (I'm not using abc, in case I'm on the wrong track).
What you are proposing is to construct an object of type X, then transform it after the fact to a Y or Z. You cannot do that in Java. The best you can do is to construct a Y or Z using the original X as an information source, replacing the original X with the new Y or Z.
The only ORM considerations here are that if you go constructing and linking objects like that, you'll want to pay attention to whether the objects are connected or not, and if they are connected, to when the changes are committed.
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: Apr 21, 2010
Yes I think you're right...
concretely my example in your letters is that X is the supertype, and Y and Z derived classes. X is abstract, so in the usercase I create an instance of Y and another of Z and depending on an alternator control, I save Y or Z. But in fact your writing reminded me that some hanging objects refrenced a parent that after the "copy" operation didn't correspond. And from my understanding I am sure that is what is causing the exception.
In other words,
I enter the user case and create instances of Y and Z. Y is the one to be saved by default. When I alternate the instance to be saved as a Z instance, all fields are copied over from Y to Z, (all shared fields of course, which are the ones declared in X). but what I forgot, is that Y and Z hold collections with other objects that have "parent" references to Y (since is the default parent), which I didn't update to Z. That is in my oppinion what causes the exception.
So thanks Tim. If I have further problems will post again in this thread. I will leave it like that if this solution succeeds, which I am pretty sure of.