Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Je voudrais faire un trigger ou un rule on delete pour
- ne pas effacer physiquement l'enregistrement
- mettre à jour dans l'enregistrement un champ 'deleted'
Il faut que ce code marche pour toutes les tables d'une db.
Toutes mes tentatives précédentes ont échoués.
Merci pour votre attention,
Mchl
Hors ligne
Cette fonctionnalité s'appelle souvent "soft delete" en anglais (je dis ça pour les recherches sur le web) et elle est généralement mise en oeuvre en donnant aux utilisateurs accès à une vue qui fait essentiellement
"SELECT * FROM table WHERE deleted=false", par opposition au fait de donner accès à la table.
Dans le cas contraire, la situation est absurde du point de vue d'une application qui ferait un DELETE dans la table suivi d'un SELECT et se retrouverait à relire les données qu'elle vient d'effacer.
Avec une vue, il faut faire des triggers INSTEAD OF pour mettre en oeuvre les écritures.
Sinon il y a une approche complètement différente qui consiste à ne pas empêcher les DELETE mais à sauver les lignes effacées via un INSERT en trigger. Ca ne nécessite pas de vue et c'est plus simple mais il faut un double de toutes les tables.
Dernière modification par dverite (01/03/2017 16:26:58)
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Merci pour votre réponse qui confirme mes recherches.
Je m'en suis tiré avec :
stmt := 'update public.'
|| quote_ident(TG_TABLE_NAME)
|| ' set deleted_when = now() ,deleted_by = '
|| ''''
|| current_user
|| '''';
case TG_TABLE_NAME
when 'tblActions' then execute stmt using old."ActionID";
when 'tblBlankRows' then execute stmt using old."BlankRowID";
.../...
(Je n'ai pas pu choisr la pk dans le tuple old comme décrit dans le post précédent.
et un trigger before delete.
Encore une petite question.
L'application front-end en VB Access ne veut voir que les records non effacés. J'ai donc crée des vues comme vous l'avez indiqué.
Mais peut-on faire librement des insert, update et delete sur ces vues ?
Et le front-end saura-t-il retrouver les relations pk/fk des tables sous-jacentes.
Encore merci pour votre attention.
Hors ligne
Oui dans les versions récentes de postgres en tout cas, il est possible d'insérer directement dans une vue, lorsque la requête de la vue est un simple filtre mono-table. Quand c'est plus compliqué il faut faire des triggers INSTEAD OF dont le code embarque l'intelligence de comment les mises à jours de vues doivent remonter dans les tables.
Exemple sur une instance 9.5:
test=# create table la_table(champ text, actif bool default true);
CREATE TABLE
test=# insert into la_table(champ) values('foo');
INSERT 0 1
test=# create view la_vue as select champ from la_table where actif=true;
CREATE VIEW
test=# insert into la_vue(champ) values('bar');
INSERT 0 1
test=# select * from la_table;
champ | actif
-------+-------
foo | t
bar | t
(2 rows)
test=# select * from la_vue;
champ
-------
foo
bar
(2 rows)
test=# delete from la_vue where champ='foo';
DELETE 1
test=# select * from la_vue;
champ
-------
bar
Et le front-end saura-t-il retrouver les relations pk/fk des tables sous-jacentes.
Je ne sais pas. Ca fait bien longtemps que je n'ai plus utilisé Access pour ma part, et je ne me souviens pas exactement de ce qu'il faisait avec l'intégrité référentielle sur des tables liées en ODBC. C'est dans l'éditeur de requêtes qu'il pré-positionne automatiquement les liens entre PK et FK? J'imagine qu'on peut s'en passer. L'intégrité référentielle sur les écritures sera contrôlée par postgres de toute manière.
Je vais répondre dans l'autre discussion pour l'écriture du SQL dynamique dans les triggers.
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Merci pour votre réponse qui confirme mon impression.
Hors ligne
Pages : 1