object references

[tom.baeyens]

> Object references. (potential problem might be the interfaces limitation)

"Miguel Valdes Faura" wrote:
This class has mainly two important attributes/fields to be persisted: "Descriptor" and "Object"

The main issue with ObjectReference is how to persist the "Object" attribute/field

[tom.baeyens]

The object doesn't need to be persisted. That is the cached object that is build from the wiring. So only the Descriptor needs to be persisted.

[porcherg]

In the current implementation, NodeBehaviour objects are added in the object field, so if this field is not persisted, NodeBehaviour are not persisted.

(The object created from a descriptor is stored in a "cache" field and this field is not persisted)

regards,
Guillaume

[tom.baeyens]

now i remember: there are 2 options.

1) either we only store the descriptors and then we need to build the node behaviour object each time.

this would mean that the xml parsing needs to be converted to descriptors.



2) alternatively, we could let the NodeBehaviour implementations inherit from ObjectReference. But then we would need a mixed inheritence mapping strategy to get 1 PVM object reference table + one table per process language.

in the second option, the objects themselves would be persisted as components. which means that the columns would be embedded in the JPDL_NODEBEHAVIOUR table

not sure if the latter is feasible. especially with JPA since there we can't mix inheritence mappings.

this approach, the xml parsings can create plain node behaviour implementation objects

[porcherg]

now i remember: there are 2 options.

1) either we only store the descriptors and then we need to build the node behaviour object each time.

this would mean that the xml parsing needs to be converted to descriptors.

If we use this strategy, to persist a simple class with 4 strings, we need to create 9 descriptors (one for the object and two for each string: the string and the field injection operation), so that means 9 entries to the db.

I think this is not a good solution as the resulting db queries would be very slow.

2) alternatively, we could let the NodeBehaviour implementations inherit from ObjectReference. But then we would need a mixed inheritence mapping strategy to get 1 PVM object reference table + one table per process language.

in the second option, the objects themselves would be persisted as components. which means that the columns would be embedded in the JPDL_NODEBEHAVIOUR table

not sure if the latter is feasible. especially with JPA since there we can't mix inheritence mappings.

this approach, the xml parsings can create plain node behaviour implementation objects

We can have table for all ObjectReference subclasses. and then each NodeBehaviour implementation are persisted in a separate table.

This way, we can have one table per process language (one subclass of ObjectReference per process language and one abstract class implementation of NodeBahaviour per process language).

The only drawback is that we'll have one table for node, one for objectreference and one for the node behaviour.


3) I see a third option for this issue: we can create one Descriptor which contains a reference to a specific NodeBehavour implementation (for example a Descriptor that contains an AbstractActivity).
Each NodeBehaviour is wrapped in a Descriptor, this descriptor is persisted as an embeddable field, and the NodeBehaviour wrapped in the descriptor is in a separate table (one per process language).

We would have: one table for the Node, one for the descriptor and one for the nodeBehaviour.

This is approximately the same result as with the second option, but with this solution, we don't have a new table for an objectreference. objectreference will just use descriptors too.

The drawback is that the descriptor table will have a lot of entries, and it has a lot of columns that are not necessary for just storing a reference.

regards,
Guillaume

[tom.baeyens]

what about having a NodeBehaviour member field in the Node next to the ObjectReference ?

as far as i understand your proposal, it is similar, but the reference to the real node behaviours is pulled up one more level to the node.

[porcherg]

what about having a NodeBehaviour member field in the Node next to the ObjectReference ?

NodeBehaviour is an interface, and it cannot be persisted directly with JPA.

By using an ObjectReference (a subclass of it for each implementation/root class of inheritence hierarchy), we are able to persist this interface.

If NodeBehaviour was an abstract class or if there was only one implementation that all NodeBehaviour implementations extends, we could directly have a NodeBehaviour member field.

Guillaume

[tom.baeyens]

since we decided to go for hibernate in the first release, we could keep the NodeBehviour pointer.

in the JPA case we could introduce an AbstractNodeBehaviour class from which all the node behaviour implementations should inherit.

[porcherg]

If Hibernate can map directly the ObjectReference (as an embedded object/ component for example), we can keep the current implementation because there is a clear separation between the concept (a node has one behaviour) and the implementation (this behaviour can be a descriptor, a java object...) With the ObjectReference, we have a single interface to access the behaviour from the Node.

What do you think ?

regards, Guillaume

[tom.baeyens]

The ObjectReference is introduced to unify all references to user code. So that user code, for which ever use case, is persisted and instantiated in the same way.

For all object references, there are 2 ways of how then can be persisted:

1) By means of storing the descriptors and wiring.

2) An object field that is directly mapped with hibernate. Then with a mixed inheritence mapping strategy, we can map this single field to a PVM table + 1 table per process language. This would be to prevent that all the node behaviour and other implementations for the process languages are always wired. Cause wiring could be a potential performance problem if it is done too much.

Apart from that, in the non-persistent way of working, it should always be possible to just inject a user code object.

We'll have to look at those use cases and define the mappings, schema and java code for this step by step and iteration by iteration.