5 Replies Latest reply on Mar 12, 2008 7:38 AM by tom.baeyens

    Comments about persistence

    porcherg

      Persistence mappings have changed in the pvm. I tried to use an updated pvm in the extensions. I have some comments about these changes:

      - mapping files renamed from pvm.*.hbm.xml to hibernate.*.hbm.xml:
      hbm.xml is already for hibernate. The pvm prefix is maybe more clear to separate pvm files from extension files.

      - table naming strategy: the default prefix is JBPM_. Previously it was PVM_.
      (This can be changed by adding an xml attribute). Can we define a prefix for each subset of mapping files ? e.g. PVM_ for pvm tables, BPEL_ for bpel extension tables...

      - processDefinition now uses a table per hierarchy inheritance strategy (subclass with discriminator column). We decided to use a joined-subclass strategy for this class, to have the pvm tables clearly separated from the extensions. The discriminator column creates a bug in the extensions as it is incompatible with a joined-subclass strategy.

      regards,
      Guillaume

        • 1. Re: Comments about persistence
          tom.baeyens

           

          "porcherg" wrote:
          - mapping files renamed from pvm.*.hbm.xml to hibernate.*.hbm.xml:
          hbm.xml is already for hibernate. The pvm prefix is maybe more clear to separate pvm files from extension files.


          that is to group all the hibernate mappings together when they are ordered alphabetically.

          "porcherg" wrote:
          table naming strategy: the default prefix is JBPM_. Previously it was PVM_.
          (This can be changed by adding an xml attribute). Can we define a prefix for each subset of mapping files ? e.g. PVM_ for pvm tables, BPEL_ for bpel extension tables...


          this is already configurable. see the hibernate configuration binding. i know, docs would be great...

          "porcherg" wrote:
          - processDefinition now uses a table per hierarchy inheritance strategy (subclass with discriminator column). We decided to use a joined-subclass strategy for this class, to have the pvm tables clearly separated from the extensions. The discriminator column creates a bug in the extensions as it is incompatible with a joined-subclass strategy.


          right. i was assuming that joined subclass mapping also required discriminators. my mistake. can you revert it ? i don't know the joined sub class mappings by heart.

          • 2. Re: Comments about persistence
            porcherg

             

            "tom.baeyens@jboss.com" wrote:
            "porcherg" wrote:
            table naming strategy: the default prefix is JBPM_. Previously it was PVM_.
            (This can be changed by adding an xml attribute). Can we define a prefix for each subset of mapping files ? e.g. PVM_ for pvm tables, BPEL_ for bpel extension tables...

            this is already configurable. see the hibernate configuration binding. i know, docs would be great...


            I've seen how to set this for a hibernate configuration (that is what I wanted to say by "This can be changed by adding an xml attribute"), but how to define it at "mappings" level ? (to have in the same hibernate configuration PVM_ and BPEL_ prefix)

            "tom.baeyens@jboss.com" wrote:

            right. i was assuming that joined subclass mapping also required discriminators. my mistake. can you revert it ? i don't know the joined sub class mappings by heart.

            ok (I change the mapping of execution as it's the same problem)

            regards,
            Guillaume

            • 3. Re: Comments about persistence
              tom.baeyens

              for the prefix: there is only one prefix that can be specified. the same prefix will be used for all the tables. in the prefix, i agree with miguel that it would *not* be a good idea to have a prefix per project. then it would become cluttered. for users, they typically only want to see the difference between the workflow tables and their own tables.

              come to think of it. the prefix naming strategy has to differentiate between the user classes and the bpm engine classes. i'll do this based on package name. i'll only apply the prefix for org.jbpm classes and for your bonita classes. what is the package name prefix for that ?

              • 4. Re: Comments about persistence

                Indeed we agreed with Tom on unifying prefixes on both pvm and extensions but there is one use case for which we could have some issues:

                In a deployment situation in which more than one extension is leveraged (i.e XPDL and BPEL) together with the PVM, we could came out to naming issues with tables having the same name in two different extensions (if keep the same prefix).

                I only see two options to solve this issue:

                - Either we check that names duplication does not occurs between extensions

                - Either we have configurables prefixes depending on the package names.

                I'm still thinking that using the same prefix is more convenient but its probably hard to ensure that no conflicts names will raise when deploying more than one extension under the same PVM...

                What do you think Tom ?

                regards,
                Miguel Valdes



                • 5. Re: Comments about persistence
                  tom.baeyens

                  i don't think it's necessary to add a check for table names on the modules. we'll be developing those modules ourselves. so we will run into trouble with our own testing if we would create a nameclash.

                  a test could be included. it could be done, but i don't see the need.