glassfish
  1. glassfish
  2. GLASSFISH-348

Bad data type auto-generated : DECIMAL 5 0 when trying a 10 2 !

    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:
      348

      Description

      BIGDECIMAL Schema column generation is broken with b39 and derby.

      Creating a new Java EE 5 project with the entity class and the persistence.xml
      will result in creating a TABLE TESTBIGDECIMAL with a column AMOUNTWITHTAXES
      that is of type DECIMAL 5 0 (and not 10 2 !!!).

      Hence, all amounts are rounded to the unit and you can not compute any money
      amount in a valid way.

      Class :

      /*

      • TestBigDecimal.java
        *
      • Created on 6 mars 2006, 16:20
        *
      • To change this template, choose Tools | Template Manager
      • and open the template in the editor.
        */

      package test;

      import java.math.BigDecimal;
      import javax.persistence.Column;
      import javax.persistence.Entity;
      import java.io.Serializable;
      import javax.persistence.GeneratedValue;
      import javax.persistence.GenerationType;
      import javax.persistence.Id;
      import javax.persistence.TableGenerator;
      import javax.persistence.Version;

      /**

      • Shows that DECIMAL(10,2) will create instead a DECIMAL(5,0)
      • Should be a bug
      • @author BJB
        */
        @Entity
        public class TestBigDecimal implements Cloneable, Serializable{

      /**

      • Unique technical identifier
        */
        private long identifier;

      /**

      • technical field for optimistic lock / version of object
        */
        private int version;

      /** Creates a new instance of TestBigDecimal */
      public TestBigDecimal() {
      }

      private BigDecimal amountWithTaxes = BigDecimal.ZERO;

      @Column(nullable=false,precision=10,scale=2)
      public BigDecimal getAmountWithTaxes()

      { return amountWithTaxes; }

      public void setAmountWithTaxes(BigDecimal amountWithTaxes)

      { this.amountWithTaxes = amountWithTaxes; }

      @Id
      @TableGenerator(name = "TEST_SEQUENCE", table = "IDGENERATOR", pkColumnName
      = "SEQ_NAME", valueColumnName = "SEQ_COUNT", pkColumnValue = "TESTIDENTIFIER",
      initialValue=0, allocationSize=1)
      @GeneratedValue(strategy = GenerationType.TABLE, generator = "TEST_SEQUENCE")
      //@Column(nullable=false, unique=true, updatable=false,insertable=false)
      public long getIdentifier()

      { return identifier; }

      public void setIdentifier(long identifier)

      { this.identifier = identifier; }

      @Version
      public int getVersion()

      { return version; }

      public void setVersion(int version)

      { this.version = version; }

      }

      And the persistence.xml :

      <?xml version="1.0" encoding="UTF-8"?>
      <persistence xmlns="http://java.sun.com/xml/ns/persistence">
      <persistence-unit name="testbig" transaction-type="JTA">
      <jta-data-source>jdbc/__default</jta-data-source>
      <properties>
      <property name="ddl-generation" value="dropandcreate"/>
      <property name="toplink.platform.class.name"
      value="oracle.toplink.essentials.platform.database.DerbyPlatform"/>
      <property name="toplink.logging.level" value="FINEST"/>
      </properties>
      </persistence-unit>
      </persistence>

      Rgs,
      JB

        Activity

        Hide
        pramodgo added a comment -

        Downgrading priority

        Show
        pramodgo added a comment - Downgrading priority
        Hide
        bjb added a comment -

        Hi pramodgo,

        Can you clarify the reason of the downgrading to P3 ?

        Does it means that support of java2db for mySQL or PostgreSQL is low priority
        given your planning ?
        Or does it means you have tested the two flavors and that the identified issue
        in the code is generated anyway some correct datatype when working on BigDecimal
        mapping (ie, either using 38,0 or generating bad synthax as it could have been
        anticipated) ?

        Rgs,
        JB

        Show
        bjb added a comment - Hi pramodgo, Can you clarify the reason of the downgrading to P3 ? Does it means that support of java2db for mySQL or PostgreSQL is low priority given your planning ? Or does it means you have tested the two flavors and that the identified issue in the code is generated anyway some correct datatype when working on BigDecimal mapping (ie, either using 38,0 or generating bad synthax as it could have been anticipated) ? Rgs, JB
        Hide
        pramodgo added a comment -

        Agree with your comments that the code should have been :

        fieldTypeMapping.put(java.math.BigDecimal.class, new
        FieldTypeDefinition("DECIMAL",38));

        Further the documentation states :
        "In standard SQL, the syntax DECIMAL(M) is equivalent to DECIMAL(M,0).
        Similarly, the syntax DECIMAL is equivalent to DECIMAL(M,0), where the
        implementation is allowed to decide the value of M. MySQL supports both of these
        variant forms of the DECIMAL and NUMERIC syntax. The default value of M is 10."

        Hence I am changing the code for MYsql and Postgresql to ensure that we create
        decimal fields with the default of 38. Thanks for pointing that out.

        Now coming to the point of downgrading this bug. You had initially filed this
        bug as P1. It was my mistake as I should have downgraded this bug right then to
        P3. A priority of P1 and P2 is generally associated to scenario where the server
        does not start, or there is an issue and there is no other workaround available
        to get around the issue.
        In case of java2db feature, there is always a workaround of manually creating
        the tables in the database. Hence the priority of P3.

        Any bug that is filed against glassfish is looked at and we try to fix that
        issue ASAP, so rest assured the motive of downgrading the bug was not because of
        any planning scenario. I hope that answers your question.

        Show
        pramodgo added a comment - Agree with your comments that the code should have been : fieldTypeMapping.put(java.math.BigDecimal.class, new FieldTypeDefinition("DECIMAL",38)); Further the documentation states : "In standard SQL, the syntax DECIMAL(M) is equivalent to DECIMAL(M,0). Similarly, the syntax DECIMAL is equivalent to DECIMAL(M,0), where the implementation is allowed to decide the value of M. MySQL supports both of these variant forms of the DECIMAL and NUMERIC syntax. The default value of M is 10." Hence I am changing the code for MYsql and Postgresql to ensure that we create decimal fields with the default of 38. Thanks for pointing that out. Now coming to the point of downgrading this bug. You had initially filed this bug as P1. It was my mistake as I should have downgraded this bug right then to P3. A priority of P1 and P2 is generally associated to scenario where the server does not start, or there is an issue and there is no other workaround available to get around the issue. In case of java2db feature, there is always a workaround of manually creating the tables in the database. Hence the priority of P3. Any bug that is filed against glassfish is looked at and we try to fix that issue ASAP, so rest assured the motive of downgrading the bug was not because of any planning scenario. I hope that answers your question.
        Hide
        pramodgo added a comment -

        Code changes have been checked in

        Show
        pramodgo added a comment - Code changes have been checked in
        Hide
        bjb added a comment -

        Hi pramodgo,

        Thanks for the clarification and the check-in !

        My understanding about priority was that it was more oriented toward
        sub-component. Hence, I put P1 because java2db was just failing to gnerate a
        valid script. Of course you can always create the script manually.

        Is there any page where the P1 - P5 level are defined ? (label help of colabnet
        is not helping much)

        This would help to better prioritize the issues on common criteria and not
        end-up in the current situation where 70% of the issues are P3 ...

        Best Regards,
        JB

        Show
        bjb added a comment - Hi pramodgo, Thanks for the clarification and the check-in ! My understanding about priority was that it was more oriented toward sub-component. Hence, I put P1 because java2db was just failing to gnerate a valid script. Of course you can always create the script manually. Is there any page where the P1 - P5 level are defined ? (label help of colabnet is not helping much) This would help to better prioritize the issues on common criteria and not end-up in the current situation where 70% of the issues are P3 ... Best Regards, JB

          People

          • Assignee:
            pramodgo
            Reporter:
            bjb
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: