glassfish
  1. glassfish
  2. GLASSFISH-139

Java2DB does not drop sequences during undeploy/redeploy

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 9.0pe
    • Fix Version/s: 9.0pe
    • Component/s: entity-persistence
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      139

      Description

      A sequence got created during first deployment, but during subsequent
      deployment, I got a warning:
      [exec] Command deploy executed successfully with following warning messages:

      [exec] JDO76614: Deployment encountered SQL Exceptions:
      [exec] JDO76609: Got SQLException executing statement "CREATE TABLE
      SEQUENCE (SEQ_NAME VARCHAR(50), SEQ_COUNT DECIMAL(15))":
      org.apache.derby.client.am.SqlException: Table/View 'SEQUENCE' already exists in
      Schema 'APP'.

      Looks like a bug to me. Given below are the DDLs generated for creation and
      dropping.

      default_pu1_createDDL.jdbc
      --------------------------
      CREATE TABLE ACCOUNT (ACCNO INTEGER NOT NULL, NAME VARCHAR(255), OPENEDON
      VARCHAR(255), BALANCE FLOAT, LASTUPDATED VARCHAR(255), PRIMARY KEY (ACCNO))
      CREATE TABLE SEQUENCE (SEQ_NAME VARCHAR(50), SEQ_COUNT DECIMAL(15))
      INSERT INTO SEQUENCE(SEQ_NAME, SEQ_COUNT) values ('SEQ_GEN', 0)

      default_pu1_dropDDL.jdbc
      ------------------------
      DROP TABLE ACCOUNT

      To recreate the issue, use any application with a persistence unit in it. The
      entity beans must use sequence generator (this is default for Derby) and use
      Java2DB feature to generate tables. Deploy using --createtables. Again redploy
      using the same option. You shall see the warning.

      Pramod confirmed that this is a known bug. Since there was no issue filed as
      yet, I am filing one.

        Activity

        Hide
        Sanjeeb Sahoo added a comment -

        Created an attachment (id=27)
        test case to reproduce. Use 'asadmin deploy --createtables issue_139.ear' to deploy the app.

        Show
        Sanjeeb Sahoo added a comment - Created an attachment (id=27) test case to reproduce. Use 'asadmin deploy --createtables issue_139.ear' to deploy the app.
        Hide
        pramodgo added a comment -

        Reassigning this issue to myself

        Show
        pramodgo added a comment - Reassigning this issue to myself
        Hide
        pkrogh added a comment -

        The TableCreation code is using createSequences - if you think that it should
        drop the sequence table, it should be using replaceSequences. Using
        createSequences was a design desision made early on in the TopLink product. I
        think, however that we should probably fix it to allow both. I also could see
        how the default for the RI could be to drop sequences:

        I would do something like this. In Table creator
        Add a new method:
        public void replaceTables
        (oracle.toplink.essentials.sessions.DatabaseSession session, SchemaManager
        schemaManager, boolean keepSequenceTable)

        { // exactly the same as the old replaceTables method except for the last line. //schemaManager.createSequences();//old last line schemaManager.createOrReplaceSequences(boolean); }

        Then (to avoid code duplication) make sure that the old method looks like this:
        public void replaceTables
        (oracle.toplink.essentials.sessions.DatabaseSession session, SchemaManager
        schemaManager)

        { replaceTables(session, schemaManager, true); }

        Last step is to make sure that your schema generation code calls the new method
        with false.

        Show
        pkrogh added a comment - The TableCreation code is using createSequences - if you think that it should drop the sequence table, it should be using replaceSequences. Using createSequences was a design desision made early on in the TopLink product. I think, however that we should probably fix it to allow both. I also could see how the default for the RI could be to drop sequences: I would do something like this. In Table creator Add a new method: public void replaceTables (oracle.toplink.essentials.sessions.DatabaseSession session, SchemaManager schemaManager, boolean keepSequenceTable) { // exactly the same as the old replaceTables method except for the last line. //schemaManager.createSequences();//old last line schemaManager.createOrReplaceSequences(boolean); } Then (to avoid code duplication) make sure that the old method looks like this: public void replaceTables (oracle.toplink.essentials.sessions.DatabaseSession session, SchemaManager schemaManager) { replaceTables(session, schemaManager, true); } Last step is to make sure that your schema generation code calls the new method with false.
        Hide
        pramodgo added a comment -

        Working on this issue

        Show
        pramodgo added a comment - Working on this issue
        Hide
        pramodgo added a comment -

        The same sequence table could be used by multiple applications, so it does not
        make sense to drop the sequence table when undeploying an application. An easier
        approch would be to delete the row from the sequence table that was inserted at
        the time of deploying the application.
        Have added code to facilitate this change.

        Show
        pramodgo added a comment - The same sequence table could be used by multiple applications, so it does not make sense to drop the sequence table when undeploying an application. An easier approch would be to delete the row from the sequence table that was inserted at the time of deploying the application. Have added code to facilitate this change.

          People

          • Assignee:
            pramodgo
            Reporter:
            Sanjeeb Sahoo
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: