DBRE Bug: TIMESTAMP column annotated as DATE for Join Table

[JeffH]

I've discovered this problem during DBRE for Roo 1.2.2.RELEASE with MySQL (5.5 on OS X 10.6). Here is a description of the join table:

mysql> describe CardActionCard;
+----------------+------------+------+-----+---------------------+-------+
| Field          | Type       | Null | Key | Default             | Extra |
+----------------+------------+------+-----+---------------------+-------+
| cardActionId   | bigint(20) | NO   |     | NULL                |       |
| cardId         | bigint(20) | NO   |     | NULL                |       |
| cardActionDate | timestamp  | NO   |     | 0000-00-00 00:00:00 |       |
+----------------+------------+------+-----+---------------------+-------+
3 rows in set (0.01 sec)

Here is the PK class (CardActionCardPK_Roo_Identifier.aj) generated by Roo during DBRE:

// WARNING: DO NOT EDIT THIS FILE. THIS FILE IS MANAGED BY SPRING ROO.
// You may push code into the target .java compilation unit if you wish to edit any member(s).

package com.foo.backoffice.model;

import com.foo.backoffice.model.CardActionCardPK;
import java.util.Date;
import javax.persistence.Column;
import javax.persistence.Embeddable;
import javax.persistence.Temporal;
import javax.persistence.TemporalType;
import org.springframework.format.annotation.DateTimeFormat;

privileged aspect CardActionCardPK_Roo_Identifier {
    
    declare @type: CardActionCardPK: @Embeddable;
    
    @Column(name = "cardActionId", nullable = false)
    private Long CardActionCardPK.cardActionId;
    
    @Column(name = "cardId", nullable = false)
    private Long CardActionCardPK.cardId;
    
    @Column(name = "cardActionDate", nullable = false)
    @Temporal(TemporalType.DATE)
    @DateTimeFormat(style = "M-")
    private Date CardActionCardPK.cardActionDate;
    
    public CardActionCardPK.new(Long cardActionId, Long cardId, Date cardActionDate) {
        super();
        this.cardActionId = cardActionId;
        this.cardId = cardId;
        this.cardActionDate = cardActionDate;
    }

    private CardActionCardPK.new() {
        super();
    }

    public Long CardActionCardPK.getCardActionId() {
        return cardActionId;
    }
    
    public Long CardActionCardPK.getCardId() {
        return cardId;
    }
    
    public Date CardActionCardPK.getCardActionDate() {
        return cardActionDate;
    }
    
}

The generated annotation for the cardActionDate member should be TIMESTAMP, not DATE.

Is the team already aware of this code-generation issue?

In a previous thread that I started, and prior to me finding this problem, someone suggested I change the hibernate.hbm2ddl.auto property in persistence.xml from "validate" to "none". What negative side effects can this have? Is it going to a problem as we evolve the schema (I would think so). Is there another workaround that has been successful? Should I just change the generated code to use a temporal type of TIMESTAMP?

Thanks,
Jeff

-Jeff

[mmartinez]

Hi Jeff one more time !

Create an issue at JIRA: https://jira.springsource.org/browse/ROO

Regards !

[JeffH]

Hi Jeff one more time !

Create an issue at JIRA: https://jira.springsource.org/browse/ROO

Regards !

Done: https://jira.springsource.org/browse/ROO-3243

-Jeff

[Alan Stewart]

The generated annotation for the cardActionDate member should be TIMESTAMP, not DATE.

Why should it be a timestamp? Please post the element from your dbre.xml file for this field. Without knowing what the type is being returned in the java.sql.DatabaseMetaData for MySQL 5.5, this may be working as designed.
Alan

[JeffH]

Why should it be a timestamp? Please post the element from your dbre.xml file for this field. Without knowing what the type is being returned in the java.sql.DatabaseMetaData for MySQL 5.5, this may be working as designed.
Alan

It should be a timestamp because that's what the database defines the column type as. I ran the DBRE from scratch again, and the XML in dbre.xml for the cardActionDate column is correctly defined as a timestamp:

    <table name="CardActionCard">
        <column name="cardActionId" primaryKey="false" required="true" scale="0" size="19" type="-5,BIGINT"/>
        <column name="cardId" primaryKey="false" required="true" scale="0" size="19" type="-5,BIGINT"/>
        <column name="cardActionDate" primaryKey="false" required="true" scale="0" size="19" type="93,TIMESTAMP"/>
    </table>

The annotation for cardActionDate, generated by Roo, in the file CardActionCardPK_Roo_Identifier.aj incorrectly annotates it as a Date.

    @Column(name = "cardActionDate", nullable = false)
    @Temporal(TemporalType.DATE)
    @DateTimeFormat(style = "M-")
    private Date CardActionCardPK.cardActionDate;

This was the only code generation error for 48 tables. Very odd. If there's anything else you can think of for me to look at, please let me know.

-Jeff

[Alan Stewart]

I've made a change to use java.sql.Timestamp, but just wanted to check first what you're expecting for the TemporalType in the @Temporal annotation and the style value for @DateTimeFormat?
Alan

[JeffH]

I've made a change to use java.sql.Timestamp, but just wanted to check first what you're expecting for the TemporalType in the @Temporal annotation and the style value for @DateTimeFormat?
Alan

Thanks for looking into this, Alan.

The database column, as described by MySQL (see my post above for the screen dump) is stored as YYYY-MM-DD HH:MM:SS so I think the generated @DateTimeFormat style must include both date and time. Since Roo thought the column was supposed to be a DATE, it used the style "M-" (e.g., "Aug 30, 1964"). Obviously, for a time stamp, we also need to include time information ("MM" = "Aug 30, 1964 11:24:41 AM").

I don't know if it's been suggested (or if the feature already exists), but being able to tell Roo how you'd like date and timestamp column formats annotated could be handy. Some people may want to use a default style, others might want their columns annotated with a specific pattern. It's not hard to modify a few annotations by hand but it would save time if you were reverse engineering a huge model with many dates and timestamps.

Thanks,
Jeff

[Alan Stewart]

https://jira.springsource.org/browse/ROO-3243 should be resolved now