-
1. Re: pvm basic persistence
tom.baeyens Nov 2, 2007 6:34 AM (in response to porcherg)i didn't see that commit. can you check it ?
-
2. Re: pvm basic persistence
porcherg Nov 5, 2007 3:20 AM (in response to 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 -
3. Re: pvm basic persistence
tom.baeyens Nov 5, 2007 5:10 AM (in response to porcherg)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 -
4. Re: pvm basic persistence
tom.baeyens Nov 5, 2007 5:28 AM (in response to porcherg)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) ....
-
5. Re: pvm basic persistence
porcherg Nov 5, 2007 5:34 AM (in response to porcherg)"tom.baeyens@jboss.com" wrote:
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 -
6. Re: pvm basic persistence
tom.baeyens Nov 5, 2007 5:46 AM (in response to porcherg)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. -
7. Re: pvm basic persistence
tom.baeyens Nov 5, 2007 7:23 AM (in response to 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
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?) -
8. Re: pvm basic persistence
tom.baeyens Nov 5, 2007 7:55 AM (in response to porcherg)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. -
9. Re: pvm basic persistence
tom.baeyens Nov 5, 2007 7:56 AM (in response to porcherg)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.
-
10. Re: pvm basic persistence
porcherg Nov 5, 2007 8:16 AM (in response to porcherg)"tom.baeyens@jboss.com" 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 ?"tom.baeyens@jboss.com" 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 ?)"tom.baeyens@jboss.com" 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. -
11. Re: pvm basic persistence
tom.baeyens Nov 5, 2007 8:33 AM (in response to porcherg)"porcherg" wrote:
"tom.baeyens@jboss.com" 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:
"tom.baeyens@jboss.com" 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:
"tom.baeyens@jboss.com" 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. -
12. Re: pvm basic persistence
tom.baeyens Nov 5, 2007 8:59 AM (in response to porcherg)ProcessDefinitionImpl processDefinition = new ProcessFactory() .initial() .nodes() .node("a") .node("b") .node("c") .endNodes() .processDefinition();
is not good to start with, i think. it should beProcessDefinitionImpl 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(); ////////////////////////////////////////////////////// }
-
13. Re: pvm basic persistence
porcherg Nov 5, 2007 9:28 AM (in response to 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 ?