Uploaded image for project: 'Spring Roo'
  1. Spring Roo
  2. ROO-3243

DBRE Bug: TIMESTAMP column annotated as DATE for Join Table

        Details

        • Type: Bug
        • Status: Resolved
        • Priority: Minor
        • Resolution: Complete
        • Affects Version/s: 1.2.2.RELEASE
        • Fix Version/s: 1.2.3.RELEASE
        • Component/s: PERSISTENCE
        • Labels:
          None
        • Environment:
          Mac OS X 10.6.8, Java 1.6.0_33-b03-424-10M3720, Roo 1.2.2.RELEASE, MySQL 5.5

          Description

          Please see the Reference URL for a complete description. In summary:

          During database reverse engineering, one of the table columns defined as a TIMESTAMP is being annotated incorrectly as a DATE. In my case, the error affects just a single JOIN table.

            Activity

            Ascending order - Click to sort in descending order
            Hide
            Permalink
            stewarta Alan Stewart added a comment -

            Jeff, can you please attach your project? I want to ensure my changes work. Use the Roo 'backup' command inside the Roo shell

            Show
            stewarta Alan Stewart added a comment - Jeff, can you please attach your project? I want to ensure my changes work. Use the Roo 'backup' command inside the Roo shell
            Hide
            Permalink
            stewarta Alan Stewart added a comment -

            Nevermind. This should be resolved now in Git ID ccfc61e22102e87deea6798d53cf58570a0fe6f1

            Show
            stewarta Alan Stewart added a comment - Nevermind. This should be resolved now in Git ID ccfc61e22102e87deea6798d53cf58570a0fe6f1
            Hide
            Permalink
            mmartinez Mario Martínez Sánchez - gvNIX - DISID added a comment -

            I have tested next:

            Oracle 10.2.0.4.0 database

            • NGFORGE: NUMBER
            • FPMIGRACION: DATE

            Reverse engineering with Oracle ojdbc14-10.2.0.5 wrapping:

            • <column name="NGFORGE" primaryKey="false" required="false" scale="0" size="22" type="3,NUMBER"/>
            • <column name="FPMIGRACION" primaryKey="false" required="false" scale="0" size="7" type="91,DATE"/>
            • @Temporal(TemporalType.DATE) ... Date fpmigracion

            Reverse engineering with Oracle ojdbc6-11.2.0.3 wrapping:

            • <column name="NGFORGE" primaryKey="false" required="false" scale="-127" size="0" type="3,NUMBER"/>
            • <column name="FPMIGRACION" primaryKey="false" required="false" scale="0" size="7" type="93,DATE"/>
            • @Temporal(TemporalType.TIMESTAMP) ... Date fpmigracion

            There are different generations according with jdbc driver version.

            Show
            mmartinez Mario Martínez Sánchez - gvNIX - DISID added a comment - I have tested next: Oracle 10.2.0.4.0 database NGFORGE: NUMBER FPMIGRACION: DATE Reverse engineering with Oracle ojdbc14-10.2.0.5 wrapping: <column name="NGFORGE" primaryKey="false" required="false" scale="0" size="22" type="3,NUMBER"/> <column name="FPMIGRACION" primaryKey="false" required="false" scale="0" size="7" type="91,DATE"/> @Temporal(TemporalType.DATE) ... Date fpmigracion Reverse engineering with Oracle ojdbc6-11.2.0.3 wrapping: <column name="NGFORGE" primaryKey="false" required="false" scale="-127" size="0" type="3,NUMBER"/> <column name="FPMIGRACION" primaryKey="false" required="false" scale="0" size="7" type="93,DATE"/> @Temporal(TemporalType.TIMESTAMP) ... Date fpmigracion There are different generations according with jdbc driver version.
            Hide
            Permalink
            stewarta Alan Stewart added a comment -

            I suggest you use the driver that does the job. DBRE is totally reliant on the column types returned from the driver.

            Show
            stewarta Alan Stewart added a comment - I suggest you use the driver that does the job. DBRE is totally reliant on the column types returned from the driver.
            Hide
            Permalink
            stewarta Alan Stewart added a comment -

            This changed now causes the issue:

            Exception Description: The type [class java.sql.Timestamp] for the attribute [updatedAt] on the entity class [class org.local.dbre.domain.Campaign] is not a valid type for a temporal mapping. The attribute must be defined as java.util.Date or java.util.Calendar.

            Tested with both Hibernate and EclipseLink
            Will need to change code

            Show
            stewarta Alan Stewart added a comment - This changed now causes the issue: Exception Description: The type [class java.sql.Timestamp] for the attribute [updatedAt] on the entity class [class org.local.dbre.domain.Campaign] is not a valid type for a temporal mapping. The attribute must be defined as java.util.Date or java.util.Calendar. Tested with both Hibernate and EclipseLink Will need to change code
            Hide
            Permalink
            stewarta Alan Stewart added a comment -

            Changed to generate java.util.Calendar fields rather than java.sql.Timestamp to prevent runtime errors. The Temporal annotation attributes remain unchanged. Resolved in Git ID a40aeb70328660e885b308ddcce5ddd695132e4e.

            Show
            stewarta Alan Stewart added a comment - Changed to generate java.util.Calendar fields rather than java.sql.Timestamp to prevent runtime errors. The Temporal annotation attributes remain unchanged. Resolved in Git ID a40aeb70328660e885b308ddcce5ddd695132e4e.

              People

              • Assignee:
                stewarta Alan Stewart
                Reporter:
                jeffh Jeff Hall
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: