In class Node, the NodeBehaviour is stored in an ObjectReference (in the object field of ObjectReference). It is the same for conditions in Transitions.
In ObjectReference, we just want to persist a wire descriptor:
"email@example.com" wrote:"porcherg" wrote:
- How to persist an ObjectReference ? (maybe this has a link with the previous question)
object references should have a memberfield that points to a descriptor. once the wire definitions, including the descriptors are mapped, that can be used.
If the object field is not persisted, the NodeBehaviour is not persisted. I think we can't persist the Object field directly because it is to generic.
How do we persist the NodeBehaviour ?
Here is what I understand for the NodeBehaviour implementations:
- we want to instantiate Nodebehaviour objects directly (for example "new Sequence() ..."), and each implementation is mapped in a separate table.
- If we want to add a new behaviour in a minor version update, we want to have a stable database scheme, as a result the new implementations of NodeBehaviour will be created by a wire descriptor.
That is why we use an ObjectReference and not a NodeBehaviour directly.
Is that right ?
I see 2 solutions:
- persist NodeBehaviour as an entity and subclass ObjectReference so as to have a specific mapping for NodeBehaviours (and the same for Conditions on transitions). I think this is already done for ActionReference, but not the class is not used.
- wrap a NodeBehaviour in a wire descriptor
If we want to persist a NodeBehaviour as an entity, we have a problem with JPA because we can't map an interface. Each extension can specify the default implementation (for example AbstractActivity for BPEL extension), but there will be no default mapping for the pvm. maybe we can add a common abstract implementation for NodeBehaviour. This abstract class can be mapped as an entity and can be set as the target entity of many-to-one relations.
If we want to wrap a NodeBehaviour in a wire descriptor, it can be difficult to define the field injections required for the creation of the object. Moreover, we can't have a separate table for each NodeBehaviour implementation.
What do you think about that ? What is the best approach for mapping NodeBehaviours ?