Horodatage de création et horodatage de la dernière mise à jour avec Hibernate et MySQL

Pour une certaine entité Hibernate, nous avons besoin de stocker son heure de création et la dernière fois qu'elle a été mise à jour. Comment concevriez-vous cela?

• Quels types de données utiliseriez-vous dans la base de données (en supposant MySQL, éventuellement dans un fuseau horaire différent de celui de la JVM)? Les types de données seront-ils sensibles au fuseau horaire?

• Quels types de données utiliseriez-vous en Java ( Date, Calendar, long, ...)?

• Qui feriez-vous pour définir les horodatages - la base de données, le cadre ORM (Hibernate) ou le programmeur d'application?

• Quelles annotations utiliseriez-vous pour le mappage (par exemple @Temporal)?

Je ne cherche pas seulement une solution de travail, mais une solution sûre et bien conçue.

Si vous utilisez les annotations JPA, vous pouvez utiliser @PrePersistet les @PreUpdatehooks d'événement le font:

@Entity
@Table(name = "entities")    
public class Entity {
  ...

  private Date created;
  private Date updated;

  @PrePersist
  protected void onCreate() {
    created = new Date();
  }

  @PreUpdate
  protected void onUpdate() {
    updated = new Date();
  }
}

ou vous pouvez utiliser l' @EntityListenerannotation sur la classe et placer le code d'événement dans une classe externe.

Vous pouvez simplement utiliser @CreationTimestampet @UpdateTimestamp:

@CreationTimestamp
@Temporal(TemporalType.TIMESTAMP)
@Column(name = "create_date")
private Date createDate;

@UpdateTimestamp
@Temporal(TemporalType.TIMESTAMP)
@Column(name = "modify_date")
private Date modifyDate;

En prenant les ressources de ce post ainsi que des informations prises à gauche et à droite de différentes sources, je suis venu avec cette solution élégante, créez la classe abstraite suivante

import java.util.Date;

import javax.persistence.Column;
import javax.persistence.MappedSuperclass;
import javax.persistence.PrePersist;
import javax.persistence.PreUpdate;
import javax.persistence.Temporal;
import javax.persistence.TemporalType;

@MappedSuperclass
public abstract class AbstractTimestampEntity {

    @Temporal(TemporalType.TIMESTAMP)
    @Column(name = "created", nullable = false)
    private Date created;

    @Temporal(TemporalType.TIMESTAMP)
    @Column(name = "updated", nullable = false)
    private Date updated;

    @PrePersist
    protected void onCreate() {
    updated = created = new Date();
    }

    @PreUpdate
    protected void onUpdate() {
    updated = new Date();
    }
}

et demandez à toutes vos entités de l'étendre, par exemple:

@Entity
@Table(name = "campaign")
public class Campaign extends AbstractTimestampEntity implements Serializable {
...
}

1. Quels types de colonnes de base de données vous devez utiliser

Votre première question était:

Quels types de données utiliseriez-vous dans la base de données (en supposant MySQL, éventuellement dans un fuseau horaire différent de celui de la JVM)? Les types de données seront-ils sensibles au fuseau horaire?

Dans MySQL, le TIMESTAMPtype de colonne passe du fuseau horaire local du pilote JDBC au fuseau horaire de la base de données, mais il ne peut stocker que des horodatages jusqu'à '2038-01-19 03:14:07.999999, ce n'est donc pas le meilleur choix pour l'avenir.

Donc, mieux vaut utiliser à la DATETIMEplace, qui n'a pas cette limite supérieure. Cependant, DATETIMEn'est pas au courant du fuseau horaire. Donc, pour cette raison, il est préférable d'utiliser UTC côté base de données et d'utiliser la hibernate.jdbc.time_zonepropriété Hibernate.

Pour plus de détails sur le hibernate.jdbc.time_zoneparamètre, consultez cet article .

2. Quel type de propriété d'entité utiliser

Votre deuxième question était:

Quels types de données utiliseriez-vous en Java (date, calendrier, long, ...)?

Côté Java, vous pouvez utiliser Java 8 LocalDateTime. Vous pouvez également utiliser l'héritage Date, mais les types de date / heure Java 8 sont meilleurs car ils sont immuables et ne font pas passer un fuseau horaire au fuseau horaire local lors de leur journalisation.

Pour plus de détails sur les types de date / heure Java 8 pris en charge par Hibernate, consultez cet article .

Maintenant, nous pouvons également répondre à cette question:

Quelles annotations utiliseriez-vous pour le mappage (par exemple @Temporal)?

Si vous utilisez LocalDateTimeou java.sql.Timestamppour mapper une propriété d'entité d'horodatage, vous n'avez pas besoin de l'utiliser, @Temporalcar HIbernate sait déjà que cette propriété doit être enregistrée en tant qu'horodatage JDBC.

Seulement si vous utilisez java.util.Date, vous devez spécifier l' @Temporalannotation, comme ceci:

@Temporal(TemporalType.TIMESTAMP)
@Column(name = "created_on")
private Date createdOn;

Mais, c'est beaucoup mieux si vous le mappez comme ceci:

@Column(name = "created_on")
private LocalDateTime createdOn;

Comment générer les valeurs de colonne d'audit

Votre troisième question était:

Qui feriez-vous pour définir les horodatages - la base de données, le cadre ORM (Hibernate) ou le programmeur d'application?

Quelles annotations utiliseriez-vous pour le mappage (par exemple @Temporal)?

Il existe de nombreuses façons d'atteindre cet objectif. Vous pouvez autoriser la base de données à le faire.

Pour la create_oncolonne, vous pouvez utiliser une DEFAULTcontrainte DDL, comme:

ALTER TABLE post 
ADD CONSTRAINT created_on_default 
DEFAULT CURRENT_TIMESTAMP() FOR created_on;

Pour la updated_oncolonne, vous pouvez utiliser un déclencheur DB pour définir la valeur de la colonne à CURRENT_TIMESTAMP()chaque fois qu'une ligne donnée est modifiée.

Ou, utilisez JPA ou Hibernate pour les définir.

Supposons que vous disposez des tables de base de données suivantes:

Et, chaque table a des colonnes comme:

• created_by
• created_on
• updated_by
• updated_on

Utilisation d'Hibernate @CreationTimestampet d' @UpdateTimestampannotations

Hibernate propose les annotations @CreationTimestampet @UpdateTimestampqui peuvent être utilisées pour mapper les colonnes created_onet updated_on.

Vous pouvez utiliser @MappedSuperclasspour définir une classe de base qui sera étendue par toutes les entités:

@MappedSuperclass
public class BaseEntity {

    @Id
    @GeneratedValue
    private Long id;

    @Column(name = "created_on")
    @CreationTimestamp
    private LocalDateTime createdOn;

    @Column(name = "created_by")
    private String createdBy;

    @Column(name = "updated_on")
    @UpdateTimestamp
    private LocalDateTime updatedOn;

    @Column(name = "updated_by")
    private String updatedBy;

    //Getters and setters omitted for brevity
}

Et, toutes les entités étendront le BaseEntity, comme ceci:

@Entity(name = "Post")
@Table(name = "post")
public class Post extend BaseEntity {

    private String title;

    @OneToMany(
        mappedBy = "post",
        cascade = CascadeType.ALL,
        orphanRemoval = true
    )
    private List<PostComment> comments = new ArrayList<>();

    @OneToOne(
        mappedBy = "post",
        cascade = CascadeType.ALL,
        orphanRemoval = true,
        fetch = FetchType.LAZY
    )
    private PostDetails details;

    @ManyToMany
    @JoinTable(
        name = "post_tag",
        joinColumns = @JoinColumn(
            name = "post_id"
        ),
        inverseJoinColumns = @JoinColumn(
            name = "tag_id"
        )
    )
    private List<Tag> tags = new ArrayList<>();

    //Getters and setters omitted for brevity
}

Pour plus de détails sur l'utilisation @MappedSuperclass, consultez cet article .

Cependant, même si les createdOnet updateOnpropriétés sont définies par la mise en veille prolongée spécifique @CreationTimestampet @UpdateTimestampannotations, la createdByet updatedByexigent l' enregistrement d' un rappel d'application, comme illustré par la solution JPA suivante.

Utilisation de JPA @EntityListeners

Vous pouvez encapsuler les propriétés d'audit dans un Embeddable:

@Embeddable
public class Audit {

    @Column(name = "created_on")
    private LocalDateTime createdOn;

    @Column(name = "created_by")
    private String createdBy;

    @Column(name = "updated_on")
    private LocalDateTime updatedOn;

    @Column(name = "updated_by")
    private String updatedBy;

    //Getters and setters omitted for brevity
}

Et créez un AuditListenerpour définir les propriétés d'audit:

public class AuditListener {

    @PrePersist
    public void setCreatedOn(Auditable auditable) {
        Audit audit = auditable.getAudit();

        if(audit == null) {
            audit = new Audit();
            auditable.setAudit(audit);
        }

        audit.setCreatedOn(LocalDateTime.now());
        audit.setCreatedBy(LoggedUser.get());
    }

    @PreUpdate
    public void setUpdatedOn(Auditable auditable) {
        Audit audit = auditable.getAudit();

        audit.setUpdatedOn(LocalDateTime.now());
        audit.setUpdatedBy(LoggedUser.get());
    }
}

Pour enregistrer le AuditListener, vous pouvez utiliser l' @EntityListenersannotation JPA:

@Entity(name = "Post")
@Table(name = "post")
@EntityListeners(AuditListener.class)
public class Post implements Auditable {

    @Id
    private Long id;

    @Embedded
    private Audit audit;

    private String title;

    @OneToMany(
        mappedBy = "post",
        cascade = CascadeType.ALL,
        orphanRemoval = true
    )
    private List<PostComment> comments = new ArrayList<>();

    @OneToOne(
        mappedBy = "post",
        cascade = CascadeType.ALL,
        orphanRemoval = true,
        fetch = FetchType.LAZY
    )
    private PostDetails details;

    @ManyToMany
    @JoinTable(
        name = "post_tag",
        joinColumns = @JoinColumn(
            name = "post_id"
        ),
        inverseJoinColumns = @JoinColumn(
            name = "tag_id"
        )
    )
    private List<Tag> tags = new ArrayList<>();

    //Getters and setters omitted for brevity
}

Pour plus de détails sur l'implémentation des propriétés d'audit avec le JPA @EntityListener, consultez cet article .

Vous pouvez également utiliser un intercepteur pour définir les valeurs

Créez une interface appelée TimeStamped que vos entités implémentent

public interface TimeStamped {
    public Date getCreatedDate();
    public void setCreatedDate(Date createdDate);
    public Date getLastUpdated();
    public void setLastUpdated(Date lastUpdatedDate);
}

Définir l'intercepteur

public class TimeStampInterceptor extends EmptyInterceptor {

    public boolean onFlushDirty(Object entity, Serializable id, Object[] currentState, 
            Object[] previousState, String[] propertyNames, Type[] types) {
        if (entity instanceof TimeStamped) {
            int indexOf = ArrayUtils.indexOf(propertyNames, "lastUpdated");
            currentState[indexOf] = new Date();
            return true;
        }
        return false;
    }

    public boolean onSave(Object entity, Serializable id, Object[] state, 
            String[] propertyNames, Type[] types) {
            if (entity instanceof TimeStamped) {
                int indexOf = ArrayUtils.indexOf(propertyNames, "createdDate");
                state[indexOf] = new Date();
                return true;
            }
            return false;
    }
}

Et enregistrez-le auprès de la fabrique de sessions

Avec la solution d'Olivier, lors des déclarations de mise à jour, vous pouvez rencontrer:

com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: la colonne «créée» ne peut pas être nulle

Pour résoudre ce problème, ajoutez updatable = false à l'annotation @Column de l'attribut "créé":

@Temporal(TemporalType.TIMESTAMP)
@Column(name = "created", nullable = false, updatable=false)
private Date created;

Merci à tous ceux qui ont aidé. Après avoir fait moi-même des recherches (je suis le gars qui a posé la question), voici ce que j'ai trouvé le plus logique:

• Type de colonne de base de données: le nombre de millisecondes indépendant du fuseau horaire depuis 1970 représenté comme étant decimal(20)parce que 2 ^ 64 a 20 chiffres et que l'espace disque est bon marché; soyons francs. De plus, je n'utiliserai DEFAULT CURRENT_TIMESTAMPni déclencheurs. Je ne veux pas de magie dans la DB.

• Java type de champ: long. L'horodatage Unix est bien pris en charge sur diverses bibliothèques, longn'a aucun problème Y2038, l'arithmétique d'horodatage est rapide et facile (principalement opérateur <et opérateur +, en supposant qu'aucun jour / mois / année ne soit impliqué dans les calculs). Et, plus important encore, les longs et les java.lang.Longs primitifs sont immuables - effectivement transmis par la valeur - contrairement à java.util.Dates; Je serais vraiment énervé de trouver quelque chose comme foo.getLastUpdate().setTime(System.currentTimeMillis())lors du débogage du code de quelqu'un d'autre.

• Le cadre ORM devrait être chargé de remplir automatiquement les données.

• Je n'ai pas encore testé cela, mais en regardant uniquement les documents, je suppose que @Temporalcela fera l'affaire; ne sais pas si je pourrais utiliser @Versionà cette fin. @PrePersistet @PreUpdatesont de bonnes alternatives pour contrôler cela manuellement. Ajouter cela au super-type de couche (classe de base commune) pour toutes les entités, est une idée mignonne à condition que vous souhaitiez vraiment un horodatage pour toutes vos entités.

Si vous utilisez l'API de session, les rappels PrePersist et PreUpdate ne fonctionneront pas selon cette réponse .

J'utilise la méthode persist () de Hibernate Session dans mon code, donc la seule façon dont je pouvais faire ce travail était avec le code ci-dessous et après cet article de blog (également publié dans la réponse ).

@MappedSuperclass
public abstract class AbstractTimestampEntity {

    @Temporal(TemporalType.TIMESTAMP)
    @Column(name = "created")
    private Date created=new Date();

    @Temporal(TemporalType.TIMESTAMP)
    @Column(name = "updated")
    @Version
    private Date updated;

    public Date getCreated() {
        return created;
    }

    public void setCreated(Date created) {
        this.created = created;
    }

    public Date getUpdated() {
        return updated;
    }

    public void setUpdated(Date updated) {
        this.updated = updated;
    }
}

Maintenant, il y a aussi des annotations @CreatedDate et @LastModifiedDate.

=> https://programmingmitra.blogspot.fr/2017/02/automatic-spring-data-jpa-auditing-saving-CreatedBy-createddate-lastmodifiedby-lastmodifieddate-automatically.html

(Framework Spring)

Le code suivant a fonctionné pour moi.

package com.my.backend.models;

import java.util.Date;

import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.MappedSuperclass;

import com.fasterxml.jackson.annotation.JsonIgnore;

import org.hibernate.annotations.ColumnDefault;
import org.hibernate.annotations.CreationTimestamp;
import org.hibernate.annotations.UpdateTimestamp;

import lombok.Getter;
import lombok.Setter;

@MappedSuperclass
@Getter @Setter
public class BaseEntity {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    protected Integer id;

    @CreationTimestamp
    @ColumnDefault("CURRENT_TIMESTAMP")
    protected Date createdAt;

    @UpdateTimestamp
    @ColumnDefault("CURRENT_TIMESTAMP")
    protected Date updatedAt;
}

Une bonne approche consiste à avoir une classe de base commune pour toutes vos entités. Dans cette classe de base, vous pouvez avoir votre propriété id si elle est communément nommée dans toutes vos entités (une conception commune), vos propriétés de date de création et de dernière mise à jour.

Pour la date de création, vous conservez simplement une propriété java.util.Date . Assurez-vous de toujours l'initialiser avec new Date () .

Pour le dernier champ de mise à jour, vous pouvez utiliser une propriété Timestamp, vous devez la mapper avec @Version. Avec cette annotation, la propriété sera mise à jour automatiquement par Hibernate. Attention, Hibernate appliquera également un verrouillage optimiste (c'est une bonne chose).

Juste pour renforcer: ce java.util.Calendern'est pas pour les horodatages . java.util.Dateest pour un moment dans le temps, agnostique des choses régionales comme les fuseaux horaires. La plupart des bases de données stockent les choses de cette façon (même si elles ne le semblent pas; il s'agit généralement d'un paramètre de fuseau horaire dans le logiciel client; les données sont bonnes)

En tant que type de données dans JAVA, je recommande fortement d'utiliser java.util.Date. J'ai rencontré des problèmes de fuseau horaire assez désagréables lors de l'utilisation de Calendar. Voir ce fil .

Pour définir les horodatages, je recommanderais d'utiliser une approche AOP ou vous pourriez simplement utiliser des déclencheurs sur la table (en fait, c'est la seule chose que je trouve jamais l'utilisation de déclencheurs acceptable).

Vous pouvez envisager de stocker l'heure en tant que DateTime et en UTC. J'utilise généralement DateTime au lieu de Timestamp en raison du fait que MySql convertit les dates en UTC et en heure locale lors du stockage et de la récupération des données. Je préfère garder tout ce genre de logique en un seul endroit (couche métier). Je suis sûr qu'il existe d'autres situations où l'utilisation de Timestamp est préférable.

Nous avons eu une situation similaire. Nous utilisions Mysql 5.7.

CREATE TABLE my_table (
        ...
      updated_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
    );

Cela a fonctionné pour nous.

Si nous utilisons @Transactional dans nos méthodes, @CreationTimestamp et @UpdateTimestamp enregistreront la valeur dans DB mais retourneront null après avoir utilisé save (...).

Dans cette situation, l'utilisation de saveAndFlush (...) a fait l'affaire

Je pense qu'il est plus simple de ne pas le faire dans le code Java, vous pouvez simplement définir la valeur par défaut de la colonne dans la définition de la table MySql.