3 Replies Latest reply on Sep 10, 2007 7:49 AM by porcherg

    Persistence status

    porcherg Novice

      I updated the persistence files:
      - JpaPersistenceSession is now only an abstract class where jpa 'standard' methods are defined. Extensions to the Jpa spec are declared as abstract methods (maybe we can move the declarations to PersistenceService interface).
      - HibernateJpaPersistenceSession, OpenjpaJpaPersistenceSession and ToplinkJpaPersistenceSession extends this abstract class and implement the extensions methods.

      These implementations have compilation dependencies with openjpa and toplink, that's why I added them in a lib/ directory (but it's only temporary, maybe these dependencies can be added in jboss repository or managed by ivy/maven)

      there are 3 methods which are implementation specific:
      - isPersistable: returns true if the class is an entity and can be persisted
      - getPrimaryKey(object) : returns the primary key for a given object
      - getPrimaryKeyType(class): returns the type of the PK for the given class.

      These methods are tested in the PrimaryKeyTest class.
      PK methods are tested with:
      - a pk of type long
      - a embeddedId pk
      - a idclass pk
      I don't know if it works with an id which is an entity.


      For the 'long' id, hibernate and toplink implementations of getPrimaryKeyType return 'java.lang.Long' instead of 'long'. Is this an issue ?

      I added a test 'testProxy' in ProcessDefinitionTest. This test fails, but this may be an example of the Proxy vs Object clash problem.

      regards,
      Guillaume

        • 1. Re: Persistence status
          mvaldes Novice

          Just add that the current db test infraestructure includes automatic test running under multiple JPA implementations (Hibernate, OpenJPA and TopLink) and multiple databases (hsqldb and Mysql).

          regards,
          Miguel Valdes

          • 2. Re: Persistence status
            Tom Baeyens Master

            i did see the setup's for testing the different jpa impls. i didn't yet see how you wanted to test multiple databases.

            please have a look at my proposal at http://wiki.jboss.org/wiki/attach?page=JbpmPvm%2Fpvm-new-test-strategy.zip

            it contains a mechanism on how to configure for multiple db in combination with a set of jpa impls.

            but on top, it uses the command pattern. so that all features can be tested *with* and *without* persistence in the same test.

            for the multiple db in combination with the jpa implementations, i use the TestSetup mechanism, but with one extra level of nesting. i took the databases as the lowest level and the jpa implementations as the highest level.

            if tests are now executed in commands (or in try-finally blocks), they take the configuration which is a combination of the database and the jpa impl.

            can you guys take a look and let me know what you think ?

            • 3. Re: Persistence status
              porcherg Novice

              I made some persistence updates:
              -implementation for cleanDb() :
              for Hibernate's implementation it is based on http://www.jboss.com/index.html?module=bb&op=viewtopic&t=117241 (there was a problem with mysql because an index is created with the foreign key and is not dropped)

              -persistence sessions and factories listen to their context and are closed when the context is closed:
              this way connections and other resources used by entitymanager are automatically released.

              -tests to run are described in an xml file and configuration files for db tests can be in a separate directory:
              If an environment variable "PVM_CONFIG_DIR" is defined (and points to a directory), the test DbProviderTests will try to load a file "db-tests.xml" in this directory.
              This file is a xml property file as defined in java.util.Properties. For each entry

              <entry key="testName">config_file.xml</entry>
              a test setup will be created with the name "testName" and the environment defined in 'PVM_CONFIG_DIR/config_file.xml'

              This can be used to define a specific test configuration that is not in the svn (and to test multiple databases).

              If the environment variable is not set, the file "db-tests.xml" from test/java/org/jbpm/db will be used.

              Do you think this test infrastructure is flexible enough for our db tests ?

              regards,
              Guillaume