OpenJPA
  1. OpenJPA
  2. OPENJPA-399

openjpa did not handle multiple schema names with same table name

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.0.1
    • Fix Version/s: 1.0.1, 1.1.0
    • Component/s: jdbc
    • Labels:
      None
    • Environment:
      JDK1.5, OPENJPA verison 580425

      Description

      Two entities have the same table name but with different schema, only one table is created. In addition, when two entities use the generatedType.AUTO for ID, only one OPENJPA_SEQUENCE-TABLE is created.

      The problem due to the SchemaGroup.findTable() which only looked for a table name from all the schemas. Once the table was found in one of the schema then it exited and assumed that the table existed. Same problem in the TableJDBCSeq.addSchema().

      1. OPENJPA_399.patch
        38 kB
        Teresa Kan
      2. OPENJPA-399_2.patch
        4 kB
        Teresa Kan
      3. OPENJPA-399_3.patch
        4 kB
        Teresa Kan

        Issue Links

          Activity

          Hide
          Teresa Kan added a comment -

          Problem has been resolved

          Show
          Teresa Kan added a comment - Problem has been resolved
          Hide
          Teresa Kan added a comment -

          We only need to create the index for the OPENJPA_SEQUENCE_TABLE for DB2/ZOS only. Therefore, move the index creation code to the DB2Dictionary.

          Show
          Teresa Kan added a comment - We only need to create the index for the OPENJPA_SEQUENCE_TABLE for DB2/ZOS only. Therefore, move the index creation code to the DB2Dictionary.
          Hide
          Teresa Kan added a comment -

          There was another problem occurred in SQLServer that the dict.getColumns() can't find the table names because openjpa alway convert the table name to upper case. The table name is case sensive on SQLServer, therefore, no tables are found. Openjpa created the tables again and failed with duplicate tables.

          The fix will introduce a getSchemaCase() method on DBDictionary. SQLServerDictionary overrides this method to return the SCHEMA_CASE_PERSERVE.

          Original code in DBDictionary on the convertSchemaCase :
          protected String convertSchemaCase(String objectName)

          { if (objectName == null) return null; if (SCHEMA_CASE_LOWER.equals(schemaCase)) return objectName.toLowerCase(); if (SCHEMA_CASE_PRESERVE.equals(schemaCase)) return objectName; return objectName.toUpperCase(); }

          Fix will be :

          protected String convertSchemaCase(String objectName)

          { if (objectName == null) return null; String scase = getSchemaCase(); if (SCHEMA_CASE_LOWER.equals(scase)) return objectName.toLowerCase(); if (SCHEMA_CASE_PRESERVE.equals(scase)) return objectName; return objectName.toUpperCase(); }
          Show
          Teresa Kan added a comment - There was another problem occurred in SQLServer that the dict.getColumns() can't find the table names because openjpa alway convert the table name to upper case. The table name is case sensive on SQLServer, therefore, no tables are found. Openjpa created the tables again and failed with duplicate tables. The fix will introduce a getSchemaCase() method on DBDictionary. SQLServerDictionary overrides this method to return the SCHEMA_CASE_PERSERVE. Original code in DBDictionary on the convertSchemaCase : protected String convertSchemaCase(String objectName) { if (objectName == null) return null; if (SCHEMA_CASE_LOWER.equals(schemaCase)) return objectName.toLowerCase(); if (SCHEMA_CASE_PRESERVE.equals(schemaCase)) return objectName; return objectName.toUpperCase(); } Fix will be : protected String convertSchemaCase(String objectName) { if (objectName == null) return null; String scase = getSchemaCase(); if (SCHEMA_CASE_LOWER.equals(scase)) return objectName.toLowerCase(); if (SCHEMA_CASE_PRESERVE.equals(scase)) return objectName; return objectName.toUpperCase(); }
          Hide
          Teresa Kan added a comment -

          I discovered another problem in GeneratedType.Sequence. If the entity did not declare a schema name and the table name was unique, the sequence was created successfully the first time. However, when I ran the test again, it can't find the sequence.
          Since the sequence name is unique within a system, therefore, we can let all sequences create in the default schema. IN this case, we can use the null schema name to search the sequences from the db. The fix will be :

          Index: openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/schema/SchemaGenerator.java
          ===================================================================
          — openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/schema/SchemaGenerator.java (revision 585254)
          +++ openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/schema/SchemaGenerator.java (working copy)
          @@ -819,8 +819,10 @@
          if (_log.isTraceEnabled())
          _log.trace(_loc.get("gen-seqs", schemaName, sequenceName));

          + // since all the sequences are generated under the default schema
          + // therefore, we can use the null schemaname to search
          Sequence[] seqs = _dict.getSequences(meta, conn.getCatalog(),

          • schemaName, sequenceName, conn);
            + null, sequenceName, conn);

          SchemaGroup group = getSchemaGroup();
          Schema schema;
          Index: openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/DB2Dictionary.java
          ===================================================================
          — openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/DB2Dictionary.java (revision 585254)
          +++ openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/DB2Dictionary.java (working copy)
          @@ -94,7 +94,7 @@
          "LONG VARCHAR FOR BIT DATA", "LONG VARCHAR", "LONG VARGRAPHIC",
          }));
          systemSchemas = new String(

          • "SYSCAT, SYSIBM, SYSSTAT, SYSIBMADM, SYSTOOLS");
            + "SYSCAT,SYSIBM,SYSSTAT,SYSIBMADM,SYSTOOLS");
            maxConstraintNameLength = 18;
            maxIndexNameLength = 18;
            maxColumnNameLength = 30;
            Index: openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/DBDictionary.java
            ===================================================================
              • openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/DBDictionary.java (revision 585254)
                +++ openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/DBDictionary.java (working copy)
                @@ -3341,7 +3341,7 @@
                try {
                int idx = 1;
                if (schemaName != null)
          • stmnt.setString(idx++, schemaName);
            + stmnt.setString(idx++, schemaName.toUpperCase());
            if (sequenceName != null)
            stmnt.setString(idx++, sequenceName);
          Show
          Teresa Kan added a comment - I discovered another problem in GeneratedType.Sequence. If the entity did not declare a schema name and the table name was unique, the sequence was created successfully the first time. However, when I ran the test again, it can't find the sequence. Since the sequence name is unique within a system, therefore, we can let all sequences create in the default schema. IN this case, we can use the null schema name to search the sequences from the db. The fix will be : Index: openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/schema/SchemaGenerator.java =================================================================== — openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/schema/SchemaGenerator.java (revision 585254) +++ openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/schema/SchemaGenerator.java (working copy) @@ -819,8 +819,10 @@ if (_log.isTraceEnabled()) _log.trace(_loc.get("gen-seqs", schemaName, sequenceName)); + // since all the sequences are generated under the default schema + // therefore, we can use the null schemaname to search Sequence[] seqs = _dict.getSequences(meta, conn.getCatalog(), schemaName, sequenceName, conn); + null, sequenceName, conn); SchemaGroup group = getSchemaGroup(); Schema schema; Index: openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/DB2Dictionary.java =================================================================== — openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/DB2Dictionary.java (revision 585254) +++ openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/DB2Dictionary.java (working copy) @@ -94,7 +94,7 @@ "LONG VARCHAR FOR BIT DATA", "LONG VARCHAR", "LONG VARGRAPHIC", })); systemSchemas = new String( "SYSCAT, SYSIBM, SYSSTAT, SYSIBMADM, SYSTOOLS"); + "SYSCAT,SYSIBM,SYSSTAT,SYSIBMADM,SYSTOOLS"); maxConstraintNameLength = 18; maxIndexNameLength = 18; maxColumnNameLength = 30; Index: openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/DBDictionary.java =================================================================== openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/DBDictionary.java (revision 585254) +++ openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/DBDictionary.java (working copy) @@ -3341,7 +3341,7 @@ try { int idx = 1; if (schemaName != null) stmnt.setString(idx++, schemaName); + stmnt.setString(idx++, schemaName.toUpperCase()); if (sequenceName != null) stmnt.setString(idx++, sequenceName);
          Hide
          Teresa Kan added a comment -

          attach final patch

          Show
          Teresa Kan added a comment - attach final patch
          Hide
          Teresa Kan added a comment -

          Kevin,
          Thanks for the comments. I fixed the code based on your comments. However, I can't determine the configuration error because I can't tell whether the null schema is valid or not.

          For the question about HashMap, yes, HashMap can handle the null key . Here is the info from java doc:
          "Hash table based implementation of the Map interface. This implementation provides all of the optional map operations, and permits null values and the null key"

          For the last question about the logic in SchemaGroup.findTable and findSequence. It is not necessary to combine them together since they have different return object. Instead of adding more checking in a common method, the current way may be ok..

          Show
          Teresa Kan added a comment - Kevin, Thanks for the comments. I fixed the code based on your comments. However, I can't determine the configuration error because I can't tell whether the null schema is valid or not. For the question about HashMap, yes, HashMap can handle the null key . Here is the info from java doc: "Hash table based implementation of the Map interface. This implementation provides all of the optional map operations, and permits null values and the null key" For the last question about the logic in SchemaGroup.findTable and findSequence. It is not necessary to combine them together since they have different return object. Instead of adding more checking in a common method, the current way may be ok..
          Hide
          Kevin Sutter added a comment -

          Comments on the patches... Overall, the concept and logic looks good. I just have a few questions/comments about the proposed code changes. Ping me if you have any questions on my abbreviated comments. Thanks.

          o The restriction about requiring schema names for all tables if you use schema names for at least one of the entities using the same table name... I'm okay with this restriction, but is there anyway that we could detect this condition? That is, if we detect the use of a "null" schema with other existing schema names, couldn't we flag this a configuration error?

          o Any updated patches should be attached to the Issue with the same name. JIRA keeps track of the older versions automatically, so you don't have to continually add a "version number" to your patch files.

          o The testcases should be provided as part of the patch file. Makes it much easier to merge the new files into an existing project. It also removes the confusion with different project names (ie. openjpa10x_2 doesn't match my project name).

          o The testcases need the Apache licensing... Take a look, you'll understand.

          o In TableJDBCSeq, the getStatus method updates are interesting. So, the previous implementation of this method didn't act on the input parameter at all? That's strange. Also, the javadoc for this method indicates that the input parameter (mapping) could be null. Is it okay for your code to use "null" as a key for the HashMap?

          o In that same file, why not just initialize _stat to the new HashMap() (similar to the original "new Status()")? And, the original declaration was final. If you use an initializer, couldn't we go back to the "final" declaration? Maybe I'm missing the reasons for your current _stat initialization.

          o In the addSchema() method, there's no longer a "fast path" return conditional at the beginning of the method. Isn't there any means of bypassing all of the processing if the table/schema already exists?

          o I'm not following your code at the end of the addSchema() method with the "Index idx" processing. It looks like this index processing is a side-effect of calling addSchema(). Is that your intent? At a minimum, this requires additional comments, but maybe it requires some re-factoring to make this clearer.

          o The processing of generating the tableName is repeated in at least three areas of TableJDBCSeq. Could a common utility method be used instead so as not to repeat the code?

          o I don't understand the comments for Column.resetTableName(). Doesn't "reset" mean to modify an existing set, yet the comment indicates that this can only be called on columns without a table set.

          o The cleanup in LocalConstraint.addColumn() looks good.

          o The logic in SchemaGroup.findTable and SchemaGroup.findSequence seems to be very close. Can any of this code be shared in a private utility method?

          That's it,
          Kevin

          Show
          Kevin Sutter added a comment - Comments on the patches... Overall, the concept and logic looks good. I just have a few questions/comments about the proposed code changes. Ping me if you have any questions on my abbreviated comments. Thanks. o The restriction about requiring schema names for all tables if you use schema names for at least one of the entities using the same table name... I'm okay with this restriction, but is there anyway that we could detect this condition? That is, if we detect the use of a "null" schema with other existing schema names, couldn't we flag this a configuration error? o Any updated patches should be attached to the Issue with the same name. JIRA keeps track of the older versions automatically, so you don't have to continually add a "version number" to your patch files. o The testcases should be provided as part of the patch file. Makes it much easier to merge the new files into an existing project. It also removes the confusion with different project names (ie. openjpa10x_2 doesn't match my project name). o The testcases need the Apache licensing... Take a look, you'll understand. o In TableJDBCSeq, the getStatus method updates are interesting. So, the previous implementation of this method didn't act on the input parameter at all? That's strange. Also, the javadoc for this method indicates that the input parameter (mapping) could be null. Is it okay for your code to use "null" as a key for the HashMap? o In that same file, why not just initialize _stat to the new HashMap() (similar to the original "new Status()")? And, the original declaration was final. If you use an initializer, couldn't we go back to the "final" declaration? Maybe I'm missing the reasons for your current _stat initialization. o In the addSchema() method, there's no longer a "fast path" return conditional at the beginning of the method. Isn't there any means of bypassing all of the processing if the table/schema already exists? o I'm not following your code at the end of the addSchema() method with the "Index idx" processing. It looks like this index processing is a side-effect of calling addSchema(). Is that your intent? At a minimum, this requires additional comments, but maybe it requires some re-factoring to make this clearer. o The processing of generating the tableName is repeated in at least three areas of TableJDBCSeq. Could a common utility method be used instead so as not to repeat the code? o I don't understand the comments for Column.resetTableName(). Doesn't "reset" mean to modify an existing set, yet the comment indicates that this can only be called on columns without a table set. o The cleanup in LocalConstraint.addColumn() looks good. o The logic in SchemaGroup.findTable and SchemaGroup.findSequence seems to be very close. Can any of this code be shared in a private utility method? That's it, Kevin
          Hide
          Teresa Kan added a comment -

          attach 2nd patch and test case:
          1) I removed the NativeJDBCSeq code since it worked as design.
          2) Include the documentation changes in the OpenJPA manaual and Ref guide
          3) inlcude the test case

          Show
          Teresa Kan added a comment - attach 2nd patch and test case: 1) I removed the NativeJDBCSeq code since it worked as design. 2) Include the documentation changes in the OpenJPA manaual and Ref guide 3) inlcude the test case
          Hide
          Kevin Sutter added a comment -

          Teresa,
          I haven't reviewed your patch yet, but I'd like to get some clarification on the problem first...

          > Although the datasource uses different schema name, openjpa only created one table for DOG but not DOG2.

          It seems that your code example is dependent on another configuration somewhere. Either a persistence.xml or orm.xml that would differentiate the schema name. Is that correct? Your text mentions a "datasource uisng a different schema name", but I'm not sure what you meant by that. Basically, you are saying that attempting to use the same table with different schemas causes a problem because we are currently not differentiating between tables with different schemas. Right?

          > 2) If multiple entities have the generatedType.AUTO, SEQUENCE, TABLE for ID and using the same table name, then each entity must have the schema name.

          Not sure I follow this. Are you stating the use of different schemas is an absolute requirement for id generation? Or, only if you are interested in keeping the id generations separate from each other? I'm trying to figure out what limitations exist under what conditions.

          And, your last example with multiple sequence generators... Did you have to change something to allow this to work? This sounds like normal, expected behavior. Did you fix something in this area?

          Finally, as part of the patch, it sounds like you are suggesting some documentation updates. Are you going to include the necessary documentation updates to clarify these restrictions? Since it sounds like we are totally broke with some of these scenarios, I'm okay with fixing the problem(s) with documentation updates. But, I don't want to fix something without documenting how it's supposed to work for our customers. Or, how we can make it work for our customers.

          I'll take a look at your patch next, but I wanted to get started with these questions.

          Thanks,
          Kevin

          Show
          Kevin Sutter added a comment - Teresa, I haven't reviewed your patch yet, but I'd like to get some clarification on the problem first... > Although the datasource uses different schema name, openjpa only created one table for DOG but not DOG2. It seems that your code example is dependent on another configuration somewhere. Either a persistence.xml or orm.xml that would differentiate the schema name. Is that correct? Your text mentions a "datasource uisng a different schema name", but I'm not sure what you meant by that. Basically, you are saying that attempting to use the same table with different schemas causes a problem because we are currently not differentiating between tables with different schemas. Right? > 2) If multiple entities have the generatedType.AUTO, SEQUENCE, TABLE for ID and using the same table name, then each entity must have the schema name. Not sure I follow this. Are you stating the use of different schemas is an absolute requirement for id generation? Or, only if you are interested in keeping the id generations separate from each other? I'm trying to figure out what limitations exist under what conditions. And, your last example with multiple sequence generators... Did you have to change something to allow this to work? This sounds like normal, expected behavior. Did you fix something in this area? Finally, as part of the patch, it sounds like you are suggesting some documentation updates. Are you going to include the necessary documentation updates to clarify these restrictions? Since it sounds like we are totally broke with some of these scenarios, I'm okay with fixing the problem(s) with documentation updates. But, I don't want to fix something without documenting how it's supposed to work for our customers. Or, how we can make it work for our customers. I'll take a look at your patch next, but I wanted to get started with these questions. Thanks, Kevin
          Hide
          Teresa Kan added a comment -

          attach the patch..

          Show
          Teresa Kan added a comment - attach the patch..
          Hide
          Teresa Kan added a comment -

          Example of the problem:
          @Entity(name="Dog")
          @Table(name="DOGTAB")

          @IdClass(DogId.class)
          public class Dog implements Serializable

          {
          @Id
          @GeneratedValue(strategy=GenerationType.AUTO)
          private int id2;
          ..
          )

          @Entity(name="Dog2")
          @Table(name="DOGTAB")

          @IdClass(DogId.class)
          public class Dog2 implements Serializable

          {
          @Id
          @GeneratedValue(strategy=GenerationType.AUTO)
          private int id2;
          ..
          )

          Although the datasource uses different schema name, openjpa only created one table for DOG but not DOG2.

          The current architecture based on the following assumption:
          Each PU has one JDBCConfiguration, each JDBCConfiguration has only one SeqValue and one TableJDBCSeq instance. These are singletons. During the JDBCConfiguration instantate phase, the TableJDBCSeq was created and setup the default schema. At this point, there was no correlation between the actual schema with the table and with the entity class. Each entity class has the SchemaGroup which contains all the schemas within this PU, but you can tell which schema is used for this entity.

          The ultimate solution is to change the JDBCConfiguration to know the entity and its schema info at the instantiation phase. Then makes the seqValue and TableJDBCSeq as singleton for each schema. I tried to figure out how to make it work but failed. I can't find any correlation between entity, schema and table name at the configuration instantiation phase.. ..

          My current solution is based on the current architecture and fix it in the TableJDBCSeq and NativeJDBCSeq. Since the TableJDBCSeq /NativeJDBCSeq is a singleton, so I put the logic to add the seq table name for each schema for this SchemaGroup.. Then during the Insert and Update the seq table, the table name will be fully quality with the schema name, so we can insert to the correct seq table..

          There are some restrictions for using multiple schemas for the same table name that we need to document:

          1) If multiple entities have the same table name, then they must be qualified with the schema name either thru the annotation or xml mapping. If one of entity does not have a schema and one entity has a schema, it still fails when the application executes again.
          2) If multiple entities have the generatedType.AUTO, SEQUENCE, TABLE for ID and using the same table name, then each entity must have the schema name.
          3) For those entities which have its unique table name within the PU, then the schema name is not required even though the entity using the generatedType of AUTO, SEQUENCE and TABLE. – this is today's implementation.

          For the generatedType.SEQUENCE, if multiple entities use different scehmas for the same table and the sequence generator are the same, then only one sequence is created and is used for all the entities. However, if each entity has its own sequence generator, then each generator will have its own sequence. For example,
          @Entity(name="Dog")
          @Table(name="DOGTAB", schema="DB2ADMIN")

          @IdClass(DogId.class)
          public class Dog implements Serializable

          {
          @Id
          @SequenceGenerator(name="myseq",sequenceName="order_seq2")
          @GeneratedValue(strategy=GenerationType.SEQUENCE,generator="myseq")
          private int id2;
          ..
          )

          @Entity(name="Dog2")
          @Table(name="DOGTAB", schema="TWC")

          @IdClass(DogId.class)
          public class Dog2 implements Serializable

          {
          @Id
          @SequenceGenerator(name="mysequence",sequenceName="order_seq9")
          @GeneratedValue(strategy=GenerationType.SEQUENCE,generator="mysequence")
          private int id2;
          ..
          )
          The output will be like this:
          executing prepstmnt 538058770 VALUES NEXTVAL FOR order_seq2
          executing prepstmnt 1078214724 VALUES NEXTVAL FOR order_seq9

          the id values are :
          after find, dog1 id2 = 425 and dog name =helloDog
          after find, dog11 id2 = 426 and dog name =helloDog1a
          after find, dog3 id2 = 5 and dog name =helloDog2
          after find, dog31 id2 = 6 and dog name =helloDog2a

          Show
          Teresa Kan added a comment - Example of the problem: @Entity(name="Dog") @Table(name="DOGTAB") @IdClass(DogId.class) public class Dog implements Serializable { @Id @GeneratedValue(strategy=GenerationType.AUTO) private int id2; .. ) @Entity(name="Dog2") @Table(name="DOGTAB") @IdClass(DogId.class) public class Dog2 implements Serializable { @Id @GeneratedValue(strategy=GenerationType.AUTO) private int id2; .. ) Although the datasource uses different schema name, openjpa only created one table for DOG but not DOG2. The current architecture based on the following assumption: Each PU has one JDBCConfiguration, each JDBCConfiguration has only one SeqValue and one TableJDBCSeq instance. These are singletons. During the JDBCConfiguration instantate phase, the TableJDBCSeq was created and setup the default schema. At this point, there was no correlation between the actual schema with the table and with the entity class. Each entity class has the SchemaGroup which contains all the schemas within this PU, but you can tell which schema is used for this entity. The ultimate solution is to change the JDBCConfiguration to know the entity and its schema info at the instantiation phase. Then makes the seqValue and TableJDBCSeq as singleton for each schema. I tried to figure out how to make it work but failed. I can't find any correlation between entity, schema and table name at the configuration instantiation phase.. .. My current solution is based on the current architecture and fix it in the TableJDBCSeq and NativeJDBCSeq. Since the TableJDBCSeq /NativeJDBCSeq is a singleton, so I put the logic to add the seq table name for each schema for this SchemaGroup.. Then during the Insert and Update the seq table, the table name will be fully quality with the schema name, so we can insert to the correct seq table.. There are some restrictions for using multiple schemas for the same table name that we need to document: 1) If multiple entities have the same table name, then they must be qualified with the schema name either thru the annotation or xml mapping. If one of entity does not have a schema and one entity has a schema, it still fails when the application executes again. 2) If multiple entities have the generatedType.AUTO, SEQUENCE, TABLE for ID and using the same table name, then each entity must have the schema name. 3) For those entities which have its unique table name within the PU, then the schema name is not required even though the entity using the generatedType of AUTO, SEQUENCE and TABLE. – this is today's implementation. For the generatedType.SEQUENCE, if multiple entities use different scehmas for the same table and the sequence generator are the same, then only one sequence is created and is used for all the entities. However, if each entity has its own sequence generator, then each generator will have its own sequence. For example, @Entity(name="Dog") @Table(name="DOGTAB", schema="DB2ADMIN") @IdClass(DogId.class) public class Dog implements Serializable { @Id @SequenceGenerator(name="myseq",sequenceName="order_seq2") @GeneratedValue(strategy=GenerationType.SEQUENCE,generator="myseq") private int id2; .. ) @Entity(name="Dog2") @Table(name="DOGTAB", schema="TWC") @IdClass(DogId.class) public class Dog2 implements Serializable { @Id @SequenceGenerator(name="mysequence",sequenceName="order_seq9") @GeneratedValue(strategy=GenerationType.SEQUENCE,generator="mysequence") private int id2; .. ) The output will be like this: executing prepstmnt 538058770 VALUES NEXTVAL FOR order_seq2 executing prepstmnt 1078214724 VALUES NEXTVAL FOR order_seq9 the id values are : after find, dog1 id2 = 425 and dog name =helloDog after find, dog11 id2 = 426 and dog name =helloDog1a after find, dog3 id2 = 5 and dog name =helloDog2 after find, dog31 id2 = 6 and dog name =helloDog2a

            People

            • Assignee:
              Teresa Kan
              Reporter:
              Teresa Kan
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development