OpenJPA
  1. OpenJPA
  2. OPENJPA-866

DBDictionary.maxTableNameLength is not checked when using SynchronizeMappings

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.2.0, 1.3.0, 2.0.0-M2
    • Fix Version/s: 1.3.0, 2.0.0-M2
    • Component/s: None
    • Labels:
      None

      Description

      Per Alan Raison's post to the dev mailing list there appears to be a problem with trimming table names when SynchronizeMappings is used.

      Here's the email that started the conversation :
      I have been writing a DBDictionary for the Ingres database and have been running the test cases. Ingres supports 32 character table names, and this has been set in the dictionary. However some tests have hit an error whereby the table name is too long for the database.

      I notice in the DBDictionary class there is a method called "getValidTableName" but this clearly isn't being used since it is trying to use a table name which is too long. Other databases (such as Oracle) also have quite a short maximum length for table names, so this problem must be able to overcome, but I can't see anything in other Dictionary classes.

      Is there anything special I should be doing to run the tests? I am currently running through mvn test.

      My draft DBDictionary class is attached along with a sample surefire report (with my username and password removed!)

      The full thread can be seen here : http://n2.nabble.com/OpenJPA-1.2.0-Test-Cases---Table-Name-too-Long-td2197132.html

        Issue Links

          Activity

          Hide
          Donald Woods added a comment -

          also included in 1.3.x as Rev778727

          Show
          Donald Woods added a comment - also included in 1.3.x as Rev778727
          Hide
          Tim McConnell added a comment -

          Another patch which to fixex the serialization problem. The DynamicTable inner class is now non-static like the DynamicColumn inner class in DynamicSchemaFactory. All JUnit testcases in the build (i.e., Derby database) work fine now....

          Show
          Tim McConnell added a comment - Another patch which to fixex the serialization problem. The DynamicTable inner class is now non-static like the DynamicColumn inner class in DynamicSchemaFactory. All JUnit testcases in the build (i.e., Derby database) work fine now....
          Hide
          Tim McConnell added a comment -

          Hi Albert, This was my fault. I will attach another patch tomorrow and will be more thorough in testing my patches. Thanks much....

          Show
          Tim McConnell added a comment - Hi Albert, This was my fault. I will attach another patch tomorrow and will be more thorough in testing my patches. Thanks much....
          Hide
          Albert Lee added a comment -

          I tried apply the patch against the trunk but mvn clean install consistently failied in:

          Results :

          Tests in error:
          testCacheMarshallerEndToEnd(org.apache.openjpa.conf.TestCacheMarshallerEndToEnd)

          Tests run: 1374, Failures: 0, Errors: 1, Skipped: 0

          I ran the with and without the patch twice and still failed the same say.

          Can you take a look and see what may be causing the problem ?

          Thanks,
          Albert Lee.

          Show
          Albert Lee added a comment - I tried apply the patch against the trunk but mvn clean install consistently failied in: Results : Tests in error: testCacheMarshallerEndToEnd(org.apache.openjpa.conf.TestCacheMarshallerEndToEnd) Tests run: 1374, Failures: 0, Errors: 1, Skipped: 0 I ran the with and without the patch twice and still failed the same say. Can you take a look and see what may be causing the problem ? Thanks, Albert Lee.
          Hide
          Alan Raison added a comment -

          Tim - thanks for that, it works a treat.

          Show
          Alan Raison added a comment - Tim - thanks for that, it works a treat.
          Hide
          Tim McConnell added a comment -

          Here is the final (hopefully) patch to fix this problem. It basically checks the dictionary before adding tables to dynamic schemas and columns to those tables. If either exceeds the maximum length specified in the dictionary the table/column names are made valid using the same dictionary. There are still problems related to reserved words for table/column names but I'll address that problem with another patch for that JIRA.

          Show
          Tim McConnell added a comment - Here is the final (hopefully) patch to fix this problem. It basically checks the dictionary before adding tables to dynamic schemas and columns to those tables. If either exceeds the maximum length specified in the dictionary the table/column names are made valid using the same dictionary. There are still problems related to reserved words for table/column names but I'll address that problem with another patch for that JIRA.
          Hide
          Tim McConnell added a comment -

          Sure Michael, I'll take care of that in the next patch once I get Alan's remaining problem(s) fixed......

          Show
          Tim McConnell added a comment - Sure Michael, I'll take care of that in the next patch once I get Alan's remaining problem(s) fixed......
          Hide
          Michael Dick added a comment -

          Regarding the entity for the testcase could we change the field names to be something shorter (ie under the 80 column limit) and use the @Column annotation if they need to be longer (which can be split across multiple lines).

          Show
          Michael Dick added a comment - Regarding the entity for the testcase could we change the field names to be something shorter (ie under the 80 column limit) and use the @Column annotation if they need to be longer (which can be split across multiple lines).
          Hide
          Alan Raison added a comment -

          It appears that the table has beenn created with the name "UNENHANCEDIDENTITYIDPROPERTYACCE" but OpenJPA is trying to access it as "UNENHANCEDIDENTITYIDPROPERTYACC1" (one letter shorter with a digit added)

          Show
          Alan Raison added a comment - It appears that the table has beenn created with the name "UNENHANCEDIDENTITYIDPROPERTYACCE" but OpenJPA is trying to access it as "UNENHANCEDIDENTITYIDPROPERTYACC1" (one letter shorter with a digit added)
          Hide
          Tim McConnell added a comment -

          Hi Alan, thanks for the feedback. I'll look at your remaining problem(s) later today/tonight to see if I can figure out what's going on.....

          Show
          Tim McConnell added a comment - Hi Alan, thanks for the feedback. I'll look at your remaining problem(s) later today/tonight to see if I can figure out what's going on.....
          Hide
          Alan Raison added a comment -

          Tim

          I've tried your patch and although it improves things somewhat, in that there are no more "table name too long" errors, I still get a number of schema-related errors. For example, with the aforementioned TestDataCachingAndUnenhancedPropertyAccess test, I get errors along the lines of:

          Table 'unenhancedidentityidpropertyacc1' does not exist or is not owned by you.

          {DELETE FROM UNENHANCEDIDENTITYIDPROPERTYACC1}

          I am, however getting some previously failing tests to pass; org.apache.openjpa.enhance.TestUnenhancedCompoundPK.testCompoundPKFieldAccessOpenJPADefined passes whereas the other three in that class do not.

          BTW apologies for claiming that your first patch did nothing; the problem was with maven/eclipse.

          Show
          Alan Raison added a comment - Tim I've tried your patch and although it improves things somewhat, in that there are no more "table name too long" errors, I still get a number of schema-related errors. For example, with the aforementioned TestDataCachingAndUnenhancedPropertyAccess test, I get errors along the lines of: Table 'unenhancedidentityidpropertyacc1' does not exist or is not owned by you. {DELETE FROM UNENHANCEDIDENTITYIDPROPERTYACC1} I am, however getting some previously failing tests to pass; org.apache.openjpa.enhance.TestUnenhancedCompoundPK.testCompoundPKFieldAccessOpenJPADefined passes whereas the other three in that class do not. BTW apologies for claiming that your first patch did nothing; the problem was with maven/eclipse.
          Hide
          Tim McConnell added a comment -

          Hi Alan, I've been testing this failure on the following databases: MySQL, PostgreSQL, DB2, Derby, and Oracle. Unfortunately, I've haven't been able to get the Ingres database working with OpenJPA using your dictionary. This second patch improves the maven build very significantly with the Oracle database, which has only a 30-character table and column limit. BTW, did you know that you have the maxColumnNameLength defined twice in your IngreDictionary class ??

          Show
          Tim McConnell added a comment - Hi Alan, I've been testing this failure on the following databases: MySQL, PostgreSQL, DB2, Derby, and Oracle. Unfortunately, I've haven't been able to get the Ingres database working with OpenJPA using your dictionary. This second patch improves the maven build very significantly with the Oracle database, which has only a 30-character table and column limit. BTW, did you know that you have the maxColumnNameLength defined twice in your IngreDictionary class ??
          Hide
          Tim McConnell added a comment -

          Attaching another patch to check the length of the table and column names when dynamically creating the database schema. It also includes a JUnit testcase to demonstrate the failure on multiple databases.

          Show
          Tim McConnell added a comment - Attaching another patch to check the length of the table and column names when dynamically creating the database schema. It also includes a JUnit testcase to demonstrate the failure on multiple databases.
          Hide
          Alan Raison added a comment -

          I've just tried to run the test "org.apache.openjpa.enhance.TestDataCachingAndUnenhancedPropertyAccess" with the patched sources, but I still get:

          Table name "UnenhancedIdentityIdPropertyAccess" is 34-character long. The database allows maximum 32-character for a table name.

          How did you test the patch? Let me know and I will try to replicate that.

          Show
          Alan Raison added a comment - I've just tried to run the test "org.apache.openjpa.enhance.TestDataCachingAndUnenhancedPropertyAccess" with the patched sources, but I still get: Table name "UnenhancedIdentityIdPropertyAccess" is 34-character long. The database allows maximum 32-character for a table name. How did you test the patch? Let me know and I will try to replicate that.
          Hide
          Alan Raison added a comment -

          You'll need the Ingres DBDictionary, which can be found at http://code.ingres.com/apps/openjpa/.

          I'm not sure that's 100% up to date, however, so I'll run on my own machine and let you know.

          Thanks

          Alan

          Show
          Alan Raison added a comment - You'll need the Ingres DBDictionary, which can be found at http://code.ingres.com/apps/openjpa/ . I'm not sure that's 100% up to date, however, so I'll run on my own machine and let you know. Thanks Alan
          Hide
          Tim McConnell added a comment -

          Adding a patch to check that the table name is valid before adding it to the schema. This fixes the problem for Oracle, which has only a 30-character maximum table length name, but should work for Ingres as well. I'll install and test with Ingres tomorrow just to be sure.

          Show
          Tim McConnell added a comment - Adding a patch to check that the table name is valid before adding it to the schema. This fixes the problem for Oracle, which has only a 30-character maximum table length name, but should work for Ingres as well. I'll install and test with Ingres tomorrow just to be sure.

            People

            • Assignee:
              Tim McConnell
              Reporter:
              Alan Raison
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development