9
votes

Déclencheurs vs. JPA @prepersist pour la création et la mise à jour des horodatages

Je construis une nouvelle application Web et j'utilise le printemps, la JPA / Hibernate et les Postgres. Certaines de mes tables ont créé des colonnes création_TS et LastUpdate_TS qui sont des colonnes horodaques qui suivent lorsqu'un insert s'est produit et lorsque la dernière mise à jour s'est produite sur une ligne.

J'utilise également une convention de dénomination pour les colonnes de mes tables afin de concevoir de la conception. Politique Chaque tableau est garanti d'avoir deux colonnes pkkey, une clé de substitution entier et une version de verrouillage optimiste.

J'ai deux façons de garder ces champs à jour.

< Strong> Option A: Utilisez des déclencheurs

C'est la solution que j'ai en place en ce moment, j'ai deux postgres déclencheurs qui incendient sur Insérer et mettre à jour et conserveront ces champs à jour. et j'ai deux classes. xxx

et j'ai xxx

Option B: Utilisez les écouteurs JPA

Dans cette option, j'utiliserais des auditeurs JPA pour garder les colonnes horodatées à jour.

Ma question:

Laquelle de ces deux approches est meilleure? Comme je vois des choses ici, c'est ma liste personnelle des avantages et des inconvénients de chaque option et je suis très intéressé d'entendre l'expérience des autres avec ces deux choix.

Option A Avantages:

  1. La base de données effectue les mises à jour avec les déclencheurs afin qu'il n'y ait aucun danger d'affichage d'horloge dans le cluster exécutant l'application Web.
  2. Si une application non-JPA accède à la base de données, l'obligation de conserver ces deux colonnes est appliquée.

    option un inconvénient:

    1. doit faire une sélection après l'insertion et la mise à jour pour lire les valeurs que les déclencheurs sont mis en place.
    2. J'utilise des annotations hibernées pour relier les valeurs

      Option B Avantages:

      1. moins de frappe lors de la création du DDL
      2. Pas besoin de lire les valeurs de retour de la base de données après insérer et mettre à jour
      3. Pure JPA Annotations Pas d'hibernation Annotations spécifiques

        Option B Inconfection:

        1. DANGER DE L'HORLOGE SKEW dans le cluster
        2. Les champs définis chaque fois que le fournisseur JPA décide d'appeler les méthodes de rappel non prévisibles

          Comment résoudre ce problème pour une nouvelle application dans laquelle vous avez le contrôle total sur la base de données et le code Java.


1 commentaires

Quelle solution a choisi Finnaly? Quels sont vos commentaires? Je suis confronté au problème: Stackoverflow.com/Questtions/11136042/ Triggers-Versus-JPA-Eve NT


3 Réponses :


6
votes

doit faire une sélection après l'insertion et la mise à jour pour lire les valeurs que les déclencheurs mises en place.

Vous pouvez utiliser insérer ... renvoyer ou Mise à jour ... renvoyer pour récupérer les valeurs modifiées par la gâchette. Il n'est donc pas nécessaire de faire un autre Sélectionnez.

En dehors de cela, je dirais que cela dépend de votre environnement. Si l'application est critique de mission et échouera lamentablement si ces colonnes ne sont pas maintenues correctement, alors je collerais avec les déclencheurs.

Si cela ne correspond que de commodité à l'avant (et il peut gérer des conflits en raison de valeurs incorrectes gracieusement), l'approche JPA est probablement plus facile à maintenir.


3 commentaires

Pourriez-vous s'il vous plaît fournir quelques détails pour insérer ... renvoyer et Mise à jour ... retourner ? Où puis-je trouver des informations sur ceux-ci?


@Skarkalykov: Voir les exemples du manuel: Postgresql.org/ Documents / actuels / statiques / sql-insert.html # AEN78304


OK, je pensais que si c'est une fonctionnalité JPA. Trouvé de cette façon en JPA: do x = em.merge (x); em.flush (); em.Reload (x);



1
votes

danger d'horloge oblique à incliner dans le cluster

Je dirais de ne pas m'inquiéter. Cela peut échouer dans le cluster juste comme s'il pouvait échouer dans la base de données. Dans un environnement de production approprié, vous auriez vos propres serveurs NTP et votre cluster se synchronise avec cela.

Je préfère généralement tout garder en Java, comme un lieu centralisé pour "logique" est souhaitable (pour moi). Placer la logique dans les déclencheurs est acceptable si vous avez des applications non Java qui le consomment.


0 commentaires

3
votes

J'utilise actuellement l'option A (avec tous vos cadres et postgreSQL également) de la manière suivante: xxx

Si vous utilisez la colonneFinition comme écrit dans le code que vous ne voulez pas Doit sélectionner l'objet à nouveau ni écrire un code pour définir la date de vos objets. Je n'ai jamais utilisé les rappels JPA autres que pour connecter le cadre d'envers, mais je peux dire que cela semble trop d'effort pour définir la date d'objets spécifiques.


0 commentaires