pvm basic persistence

[porcherg]

I submitted a basic mapping for process definition, node, transition and nodebehaviour, with some unit tests.

I added a SignalCommand for testing execution from commands (but this is still a test).

I updated the wiki page with persistence ideas for definition. I will add some comments about the execution next week.

I started to look at the transactions, it is an important part (if we want to test the pvm in synchronous/asynchronous mode...) I have comments about this part, I think I'll write a post about this next week.

(I won't be available until Monday)

regards,
Guillaume

[tom.baeyens]

i didn't see that commit. can you check it ?

[porcherg]

i'm sorry I didn't see that the commit failed because of conflicting changes in the test infrastructure.

I modified my files and submitted them again.

Guillaume

[tom.baeyens]

i see you moved the resources from src/java back to src/resources

any perticular reason ?

i moved them originally to have easier build scripts and easier ivy test configurations for modules that are dependent on pvm

[tom.baeyens]

also, the db tests seem to fail, but maybe i'm doing something wrong. could you verify it in your environment ?

org.jbpm.wire.WireException: couldn't initialize object 'org.jbpm.base.HibernateSchemaHelper': An association from the table PVM_EXECUTION_ refers to an unmapped class: org.jbpm.pvm.Transition
 at org.jbpm.wire.descriptor.ObjectDescriptor.initialize(ObjectDescriptor.java:214)
 at org.jbpm.wire.WireContext.performInitialization(WireContext.java:549)
 at org.jbpm.wire.WireContext.initialize(WireContext.java:508)
 at org.jbpm.wire.WireContext.create(WireContext.java:467)
 at org.jbpm.wire.WireContext.create(WireContext.java:455)
....

[porcherg]

i see you moved the resources from src/java back to src/resources
any perticular reason ?

It's just that Hibernate files are not java code so I find it strange to put them in src/java. As these files are resources, I put them in src/resource (I forgot you moved them from this directory to src/java).

Guillaume

[tom.baeyens]

yeah. we could do both ways.

but since those resources should be included in the jar file, i thought it would be more convenient to just put them there. other wise the bulid scripts need to be customized.

i'll move them back to the sources for now. If you encounter more reasons to move them to a separate resources folder, we can always go back.

[tom.baeyens]

3 remarks about the committed persistence:

1) i couldn't figure out why the TransitionImpl type was not picked up for field ExecutionImpl.transition

the reported problem is that class org.jbpm.pvm.Transition is not a persistent class. but it should find the TransitionImpl as the type of the member field. Somehow it finds the property type instead.

only when adding class="TransitionImpl" the ...Impl class was picked up

2) we should use char's instead of strings as the discriminator type. full type names are to long IMO. then we should include a mapping in comments in the neighbourhood of the superclass to make it easy to find a new freely available char.

3) i'm still looking into the persistence of the wait state. i would like the concrete classes to be tested in the actual process languages. but i don't know yet what is the common part that will remain in the pvm (if any?)

[tom.baeyens]

2 notes about testing

1) All db tests should end with DbTest

2) Probably this comment is too soon as you just got started. But I still would like to mention it :-) I would like to see more systematic testing. First a test that tests the properties, then a test that shows the relations. For each relation, bidirectional references should be verified (if they are present). Then we need to find the combinations of nesting and other process structures.

regards, tom.

[tom.baeyens]

especially, on testing the combinations of different parts and structures, i don't yet see how we must do it. i just know that we should work it out as carefull and as systematic as we can.

[porcherg]

3 remarks about the committed persistence:

1) i couldn't figure out why the TransitionImpl type was not picked up for field ExecutionImpl.transition

the reported problem is that class org.jbpm.pvm.Transition is not a persistent class. but it should find the TransitionImpl as the type of the member field. Somehow it finds the property type instead.

only when adding class="TransitionImpl" the ...Impl class was picked up

I've seen this for NodeImpl and ProcessDefinitionImpl, but I didn't have the bug for execution.

As we just want to persists the PVM, for each association with an interface, we can specify "class=implementation class". Is that right ?

2) we should use char's instead of strings as the discriminator type. full type names are to long IMO. then we should include a mapping in comments in the neighbourhood of the superclass to make it easy to find a new freely available char.

I tried to do this when I first wrote the mappings with JPA, I used string when switching to Hibernate just because it was quicker. I'll change it (it is sometimes hard to find a char that represents well a class: for example B goes for BooleanDescriptor ? ByteDescriptor ? BusinessCalandarDescriptor ?)

3) i'm still looking into the persistence of the wait state. i would like the concrete classes to be tested in the actual process languages. but i don't know yet what is the common part that will remain in the pvm (if any?)

If we want to test execution in the pvm, we need to map some concrete class in pvm tests (for example WaitState). If there is no behaviour, the execution fails.

[tom.baeyens]

"porcherg" wrote:

3 remarks about the committed persistence:

1) i couldn't figure out why the TransitionImpl type was not picked up for field ExecutionImpl.transition

the reported problem is that class org.jbpm.pvm.Transition is not a persistent class. but it should find the TransitionImpl as the type of the member field. Somehow it finds the property type instead.

only when adding class="TransitionImpl" the ...Impl class was picked up

I've seen this for NodeImpl and ProcessDefinitionImpl, but I didn't have the bug for execution.

As we just want to persists the PVM, for each association with an interface, we can specify "class=implementation class". Is that right ?

that is a solution. but i still can't explain why hibernate doesn't pick up the classes automatically. it should.

i would like to know the problem before we introduce a solution :-)

"porcherg" wrote:

2) we should use char's instead of strings as the discriminator type. full type names are to long IMO. then we should include a mapping in comments in the neighbourhood of the superclass to make it easy to find a new freely available char.

I tried to do this when I first wrote the mappings with JPA, I used string when switching to Hibernate just because it was quicker. I'll change it (it is sometimes hard to find a char that represents well a class: for example B goes for BooleanDescriptor ? ByteDescriptor ? BusinessCalandarDescriptor ?)

that needs to be documented. for each class that has subclasses, you heed to have a comment following the descriminator element. in that comment you document the mappings. e.g.

<!--
B: org.jbpm.descriptors.BooleanDescriptor
...
-->

"porcherg" wrote:

3) i'm still looking into the persistence of the wait state. i would like the concrete classes to be tested in the actual process languages. but i don't know yet what is the common part that will remain in the pvm (if any?)

If we want to test execution in the pvm, we need to map some concrete class in pvm tests (for example WaitState). If there is no behaviour, the execution fails.

[tom.baeyens]

ProcessDefinitionImpl processDefinition = new ProcessFactory()
 .initial()
 .nodes()
 .node("a")
 .node("b")
 .node("c")
 .endNodes()
 .processDefinition();

is not good to start with, i think. it should be

ProcessDefinitionImpl processDefinition = new ProcessFactory()
 .node("a")
 .node("b")
 .node("c")
 .processDefinition();

initial node, nested nodes and all kinds of combinations should be tested as well later on. maybe nested node structure persistence deserves a separate test class...

that is what I have added as an example before. i also would like to try that we always add the comment markers to indicate transaction boundaries. something like this:

public void testProcessDefinitionProperties() {
 beginTransaction(); ///////////////////////////////////////////////////////

 ...

 newTransaction(); /////////////////////////////////////////////////////////

 ...

 commitTransaction(); //////////////////////////////////////////////////////
 }

[porcherg]

The testProcessDefinitionNodes test fails because of a limitation in Hibernate:

Due to the underlying relational model, collection-valued properties do not support null value semantics; Hibernate does not distinguish between a null collection reference and an empty collection.

(http://www.hibernate.org/hib_docs/reference/en/html/collections.html)

Is there locations in the code where this has a big impact ?