8 Replies Latest reply on Aug 29, 2017 12:40 PM by Scott Marlow

    'hibernate.id.new_generator_mappings' configuration trouble blocking migration

    Chris Poulsen Newbie

      Hi,

       

      I'm currently looking into migrating a lot of JBoss AS 5.1.0 based applications to Wildfly 9.

       

      The JPA entities use @GeneratedValue(AUTO) so something needs to change to get things working on installations where the NATIVE strategy relies on features like autoincrement (mysql etc.). (We currently have MySQL, Oracle and MS SqlServer instances)

       

      My initial idea was to specify the hibernate.id.new_generator_mappings=false in a system property in (standalone.xml) for those systems that needs to be backwards compatible, while setting up new systems would use the new default. (postponing the pain of figuring out and correcting the issue).

       

      However wildfly always forces the hibernate.id.new_generator_mappings=true if not specified in the persistence.xml (disregarding the System Property saying it is false).


      Is there any way of making this work like I want? (We already build several variants of the PU jars, I'd rather not double that amount just to be able to control this setting).


      On a side note:

      What would be the recommended way of not ending up in a similar mess again - I'm thinking of explicitly specifying that a SequenceStyleGenerator (for example, suggestions welcome) should be used for new installations (both app server versions).

       

      --

      Chris

        • 1. Re: 'hibernate.id.new_generator_mappings' configuration trouble blocking migration
          Scott Marlow Master

          I don't think that Hibernate took it lightly when the new (improved) id generators were added, which is why the old id generators were kept around. 

           

          Were you lucky enough to get "unique key already exists" type errors when the wrong sequence number generator was used?  I believe that this issue was documented in our EAP 6.x release notes.  It is also mentioned in a few different community documents (for those lucky enough to find/read them).  Look at How do I migrate my application from AS5 or AS6 to AS7 and migrating from AS5 to WildFly.  You might also read migrating from AS7 to WildFly (doesn't mention the new_generator_mappings setting but has other tips). 

           

          Also, look at https://docs.jboss.org/author/display/WFLY10/JPA+Reference+Guide#JPAReferenceGuide-Hibernateproperties, which describes the new_generator_mappings setting.

           

          By the way, starting with Hibernate 5 (which is in WildFly 10.0.0.Final), hibernate.id.new_generator_mappings defaults to true.  I like the idea of being able to specify default persistence unit properties to be used, although I think that is a separate concern than the one raised by your post.  Currently, you have to update all of your applications persistence.xml. 


          Look in the Hibernate doc for an example of specifying "<generator class="org.hibernate.id.TableHiLoGenerator">", I think you will want to look at using org.hibernate.id.enhanced.SequenceStyleGenerator for the generator class.

           

          Scott

          • 2. Re: 'hibernate.id.new_generator_mappings' configuration trouble blocking migration
            Chris Poulsen Newbie

            Hi Scott,

             

            Thank you for the reply!

             

            I know that hibernate did not change the mapping strategies without a good reason (I already read up on that part), that is exactly why I would like to use their new generators for new installations (and also for our existing installations on a slightly longer term).

             

            And yes, we were lucky to receive the constraint violation errors immediately when the app was tested on Wildfly.

             

            Thank you for the references, I hope they can help minimizing the risk of having to repeat this schema/data upgrade exercise later on.

             

            I'm sad to hear that the only way to currently choose between the generators is to roll 2 versions of all our existing PU jars (we already have too many configuration variants for my liking, controlling the parameters using system properties to bring down the amount of PU jar variants was one idea ).

             

            I'm surprised that Wildfly is so adamant about enabling the new generators - I would expect it to respect my settings and only enable the new generators as a reasonable default is missing. (other hibernate settings seems to support being defined as standalone.xml system properties and I see that starting wildfly with a -D<generator setting> ends up with the property being passed to hibernate twice with both a true and false value - the current mechanism seems inconsistent).

             

            Is there a realistic chance that wildfly will allow us better control of the generator mappings setting in near future? (say 3 months)

             

            --

            Chris

            • 3. Re: 'hibernate.id.new_generator_mappings' configuration trouble blocking migration
              Scott Marlow Master

              I'm sad to hear that the only way to currently choose between the generators is to roll 2 versions of all our existing PU jars (we already have too many configuration variants for my liking, controlling the parameters using system properties to bring down the amount of PU jar variants was one idea ).

              My preference would be for a patch to WildFly, that allows any persistence property to be specified globally, via standalone.xml configuration settings.  If we don't do that, next best thing could be a system property override.  I think the precedence ordering would be something like the following:

              1. persistence.xml settings take precedence over global settings. 
              2. global settings take precedence over the WildFly JPA container/deployer code that.
              3. The WildFly JPA container/deployer sets certain PU integration properties if those properties are not already set in the persistence.xml PU or global settings.

               

              The system property check idea is a good alternative which would also be specified in the standalone.xml:

              <system-properties>

               

                 <property name="hibernate.id.new_generator_mappings" value="false"/>

              </system-properties>

               

              I'm surprised that Wildfly is so adamant about enabling the new generators - I would expect it to respect my settings and only enable the new generators as a reasonable default is missing. (other hibernate settings seems to support being defined as standalone.xml system properties and I see that starting wildfly with a -D<generator setting> ends up with the property being passed to hibernate twice with both a true and false value - the current mechanism seems inconsistent).

              Are you saying that Hibernate is reading the hibernate.id.new_generator_mappings system property setting?

               

              Is there a realistic chance that wildfly will allow us better control of the generator mappings setting in near future? (say 3 months)

              I think that this is sounding like a reasonably small code change (a few lines for checking for security manager permissions to read system properties and a few lines changed to use the system property value).  Do you want to create a WFLY jira for this? In terms of scheduling, I cannot promise when the patch will be merged in.  We are working on WildFly 10.1.0 currently.  If you were able to submit a patch soon, it would probably make it in (I have no idea when WildFly 10.1.0 will be complete).  If its really important to have a fix soon, consider buying EAP.  If you won't be submitting a patch for the WFLY issue, just don't assign it to yourself.  Please update this thread with the WFLY issue link after you create it.

               

              I really appreciate hearing about this problem.  Thank you for taking the time to report it!

               

              Scott

              • 4. Re: 'hibernate.id.new_generator_mappings' configuration trouble blocking migration
                Scott Marlow Master

                Looks like Hibernate would also read the system property setting as well.  Thanks for pointing out that conflict also, that would be addressed by a code change in WildFly. 

                • 5. Re: 'hibernate.id.new_generator_mappings' configuration trouble blocking migration
                  Chris Poulsen Newbie

                  I've created an issue ( [WFLY-6149] Improve control over 'hibernate.id.new_generator_mappings' setting - JBoss Issue Tracker ) that hopefully covers what you proposed.

                   

                  We've decided to take the bull by the horns and fix our code / data / schemas to use a more explicit generator configuration, before beginning the Wildfly upgrades, so we'll not be blocked by the issue.

                  • 6. Re: 'hibernate.id.new_generator_mappings' configuration trouble blocking migration
                    Scott Marlow Master

                    Thanks again Chris, I'll probably address this issue in a future release of WildFly.  I don't think it will be very difficult.  If you or anyone else is interesting in contributing to WildFly, I think this would be a good issue to start with.  I'd be happy to provide guidance on making the change.

                     

                    Scott

                    • 7. Re: 'hibernate.id.new_generator_mappings' configuration trouble blocking migration
                      Yoni Mazar Newbie

                      Hi Scott,

                       

                      I am trying to upgrade an EJB project that we have from JBoss 4.2.3 to Wildfly 9.0.1

                       

                      All our entities are inheriting from a supper class named RootEntity which has the Id property as you can see below:

                       

                      @Id

                        @Column(name = COLUMN_ID)

                        @GeneratedValue(strategy = GenerationType.TABLE, generator = GENERATOR)

                        @TableGenerator(name = GENERATOR, table = GENERATED_IDS_TABLE_NAME, schema = "Common")

                        protected long id;

                       

                      This setting works fine on 4.2.3 (Hibernate creates a row for each entity type in the Id generation table), but when I upgraded to 9.0.1 I got "cannot read or init hi value".

                      I have spent few days trying to work around this issue - I tried to create a persistence.xml file with the following property

                       

                      <property name="hibernate.id.new_generator_mappings" value="false"></property>

                       

                      as mentioned in this thread, but this didn't help - I got an "unknown error" and I wasn't able to get this working. I even tried to specify the names of the key and value columns in the @TableGenerator attribute but It still didn't solve the issue

                       

                      I am trying to come up with an elegant solution that will allow me to do the migration without significant code/db schema changes (While maintaining backward compatibility) and I would appreciate any advice you can give me on this.

                       

                      Thanks,

                       

                      Yoni

                      • 8. Re: 'hibernate.id.new_generator_mappings' configuration trouble blocking migration
                        Scott Marlow Master

                        From a discussion in the Hibernate ORM Dev Hipchat room, I heard that Hibernate ORM is looking into having system properties take precedence over the persistence.xml settings.