Date de modification dans ToPIA
Salut, Je me demande si on ne pourrais pas gérer, de façon transparents pour l'utilisateur, les dates de modifications dans ToPIA ? À priori on sait intercepter toute opération de mise à jour avec ToPIA et donc injecter la date courante. Je verrais bien 2 modes différents (configurables) : - technique : toutes les entités ont un champ updateDate qui est mis à jour à chaque sauvegarde (attention, sauvegarde != modification) ; - métier : l'utilisateur ajoute un champ sur son entité (ex: "toto") et dans un tag-value il dit que ce champ doit contenir la date de màj. Le 2ème a surtout pour but de ne pas utiliser un champ technique dans le code métier. Il y a aussi le champ version qu'il faudrait peut-être remettre au goût du jour ? À vos avis. Arnaud
Le 29/11/2013 19:06, Arnaud Thimel a écrit :
Je me demande si on ne pourrais pas gérer, de façon transparents pour l'utilisateur, les dates de modifications dans ToPIA ?
Ça aiderait, mais c'est pas simple.
À priori on sait intercepter toute opération de mise à jour avec ToPIA et donc injecter la date courante.
Je verrais bien 2 modes différents (configurables) : - technique : toutes les entités ont un champ updateDate qui est mis à jour à chaque sauvegarde (attention, sauvegarde != modification) ; - métier : l'utilisateur ajoute un champ sur son entité (ex: "toto") et dans un tag-value il dit que ce champ doit contenir la date de màj.
Le 2ème a surtout pour but de ne pas utiliser un champ technique dans le code métier.
Il y a aussi le champ version qu'il faudrait peut-être remettre au goût du jour ?
Oui. Comme évoqué par oral, il faudrait d'abord définir précisément ce qu'on entend « modification ». S'il s'agit de la date à laquelle l'objet a été enregistré pour la dernière fois, c'est facile. Si c'est pour savoir la date à laquelle il a vraiment été modifié (changement d'une valeur d'un champs), c'est beaucoup plus chaud. Comme tu dis, sauvegarde != modification. À chaque sauvegarde, va falloir comparer l'objet champ par champ. Sans compter que l'objet modifié peut faire partie d'une grappe qui a été sauvée et l'objet se retrouve sauvegardé par cascade. Donc en gros, faudrait comparer tous les objets concernés par le cascade save et tous les comparer à leur ancien état pour savoir lesquels doivent voir leur date de modification changée. Un sacré foutoir. Un truc qui pourrait nous aider, serait d'introduire dans l'entité, un flag qui vaut false, et on surcharge tous les setters pour le passer à true comme ça, à la sauvegarde, on peut repérer ceux qui ont changés. Sauf que ça gère pas les collections qui auront été modifiées directement sans passer par la méthode sur l'entité, ni le cas où tu set une autre valeur et tu re-set l'ancienne valeur (dans ce cas, le flag a changé mais l'objet non)... Assez compliqué tout ça...
À vos avis.
Du coup, z'avez fait un truc finalement ? -- Brendan Le Ny, Code Lutin bleny@codelutin.com (+33) 02 40 50 29 28
On Mon, 09 Dec 2013 15:17:22 +0100 Brendan Le Ny <bleny@codelutin.com> wrote:
Le 29/11/2013 19:06, Arnaud Thimel a écrit :
Je me demande si on ne pourrais pas gérer, de façon transparents pour l'utilisateur, les dates de modifications dans ToPIA ?
Ça aiderait, mais c'est pas simple.
À priori on sait intercepter toute opération de mise à jour avec ToPIA et donc injecter la date courante.
Je verrais bien 2 modes différents (configurables) : - technique : toutes les entités ont un champ updateDate qui est mis à jour à chaque sauvegarde (attention, sauvegarde != modification) ; - métier : l'utilisateur ajoute un champ sur son entité (ex: "toto") et dans un tag-value il dit que ce champ doit contenir la date de màj.
Le 2ème a surtout pour but de ne pas utiliser un champ technique dans le code métier.
Il y a aussi le champ version qu'il faudrait peut-être remettre au goût du jour ?
Oui.
Comme évoqué par oral, il faudrait d'abord définir précisément ce qu'on entend « modification ». S'il s'agit de la date à laquelle l'objet a été enregistré pour la dernière fois, c'est facile. Si c'est pour savoir la date à laquelle il a vraiment été modifié (changement d'une valeur d'un champs), c'est beaucoup plus chaud. Comme tu dis, sauvegarde != modification.
À chaque sauvegarde, va falloir comparer l'objet champ par champ. Sans compter que l'objet modifié peut faire partie d'une grappe qui a été sauvée et l'objet se retrouve sauvegardé par cascade. Donc en gros, faudrait comparer tous les objets concernés par le cascade save et tous les comparer à leur ancien état pour savoir lesquels doivent voir leur date de modification changée.
Un sacré foutoir.
Un truc qui pourrait nous aider, serait d'introduire dans l'entité, un flag qui vaut false, et on surcharge tous les setters pour le passer à true comme ça, à la sauvegarde, on peut repérer ceux qui ont changés. Sauf que ça gère pas les collections qui auront été modifiées directement sans passer par la méthode sur l'entité, ni le cas où tu set une autre valeur et tu re-set l'ancienne valeur (dans ce cas, le flag a changé mais l'objet non)...
Assez compliqué tout ça...
À vos avis.
Du coup, z'avez fait un truc finalement ?
Pour la version, on utilise déjà une notion d'hibernate en format integer (incrément à chaque mis à jour de la base) http://docs.jboss.org/hibernate/orm/3.3/reference/en/html/mapping.html#mappi... Il existe aussi une autre notion timestamp http://docs.jboss.org/hibernate/orm/3.3/reference/en/html/mapping.html#mappi... -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 http://www.codelutin.com email: chemit@codelutin.com twitter: https://twitter.com/tchemit
participants (3)
-
Arnaud Thimel -
Brendan Le Ny -
Tony Chemit