Merge avec multiple statement

Bonjour mes amis

Votre humble serviteur requiert votre aide.

J'ai une requête simple, un merge comme il y a des centaines.
Pour la clause matched => Je fais un update de ma cible
Pour la clause not matched => Je fais un insert dans ma cible

Jusque là, vraiment rien d'extraordinaire. Maintenant, j'aimerais rajouter une condition :
Si on fait une insertion dans la table cible (donc not matched) j'aimerais aussi faire un update dans ma source (Donc où je fais mon select) pour changer un flag d'une colonne. (Mettre la colonne "exported" à la valeur "true" là où elle a la valeur "false" par défaut)

Je n'ai pas mis ma requête sachant qu'il s'agit d'une merge totalement classique mais si besoin, je la rajouterais sans soucis.
J'ai cherché, je n'arrive pas à trouver la possibilité de faire deux update dans la clause "not matched".

Potentiellement, je peux le faire hors du merge, mais ca rajouterais des lignes dans un script dont je me passerais bien. Donc si vous auriez des idées incroyablement géniales, je suis preneur. Sinon tant pis

Bisous

Ce n'est pas possible dans une seule instruction.

Bonsoir,

Citation:

---

Envoyé par JeanYvette

Si on fait une insertion dans la table cible (donc not matched) j'aimerais aussi faire un update dans ma source (Donc où je fais mon select) pour changer un flag d'une colonne. (Mettre la colonne "exported" à la valeur "true" là où elle a la valeur "false" par défaut)

---

Quelle drôle d'idée que de ne flaguer que les lignes qui ont été insérées dans la table "d'en face".
Existe t'il un fort % de lignes qui ne seront que updatées ?
Peut importe, c'est pas la question.

Pour une fois M$ est plus pertinent en fournissant la clause OUTPUT.
Oracle n'a pas implémenté le RETURNING pour l'instruction MERGE (pourtant dispo pour insert ou update) :(

Solutions envisagées :
1- ré-écrire le MERGE en 2 instructions pour bénéficier de RETURNING
2- Si la destination à une colonne "date_creation", s'en servir pour identifier les lignes dans la source
3- Faire une vue pour la destination et créer un trigger "INSTEAD OF insert"

NB : au passage j'en profiterais pour flaguer les lignes sources qui ont servies à un update car la ligne était déjà présente dans la destination (différents flux).

Mais bon, pas de miracle.
Comme pressenti et affirmé par Waldar, pas possible en 1 seule instruction => plus de code

Bonjour,

Merci à tous, c'est bien ce que je craignais malheureusement.
Le fait de flaguer ce qui est inséré a été volontairement simplifié de ma part, c'est pour cela que ca peut paraitre étrange.

J'ai pu faire des recherches hier dans la soirée et je vais surement adapter ce post :
http://www.oracle-developer.net/display.php?id=220

Merci pour votre aide

Bisous

Bonsoir,

Citation:

---

Envoyé par JeanYvette

J'ai pu faire des recherches hier dans la soirée et je vais surement adapter ce post :
[URL="http://www.oracle-developer.net/display.php?id=220"]http://www.oracle-developer.net/display.php?id=220[/URL

---

Merci pour ce lien ;)

Entre toutes les solutions je pense qu'une solution "en 2 temps" (ie identifier les lignes insérées puis mettre à jour la source) sera la plus robuste à la montée en charge tout en étant la plus "maintenable" car le code ne sera pas "caché" au détours d'une instruction.
Mais ça alourdira le code existant.

A voir en fonction des réalités terrain.

Bonjour,

Désolé, je n'avais pas vu ta réponse.
Quand tu parles de le faire dans le code déjà existant, tu veux dire de le faire sans package du coup ?

En fait l'avantage du package que je vois c'est qu'il permet un retour en comptant le nombre d'insert/update de fait et qu'il est adaptable. Si je prend la fonction merge counter qui est utilisée, en rajoutant des paramètres autre que c_inserted par exemple, je pourrais palier à de nouveaux problèmes, dans le futur, sur d'autres cas de merge.
C'est cette partie évolutive qui a fait que cette solution était à mes yeux la meilleure

Bonjour,

Je trouve "l'astuce" super maligne :roi:

Par contre, en m'imaginant avoir à relire :

Code:

---

1 2 3

CASE etl.merge_counter(etl.c_inserting) WHEN 0 THEN es.empno END

---

Je ne sais pas quel aurait été ma réaction.

Un Case sans aucune alternative, m'aurait très certainement attiré l’œil avec une furieuse envie de simplifier.
Du coup je serais allé voir le package.
Essayer de le comprendre le truc par l'appel m'aurait pris un certain temps.

Donc, à moins de documenter sérieusement chaque appel, je trouve que c'est un piège à la relecture.

A voir avec vos collègues s'ils ont la même sensibilité que moi.

Il est vrai que je n'y avais pas pensé. J'ai aussi eu quelque secondes de bug du cerveau quand j'ai lu ça :ptdr:

J'ai expliqué à mes collègues le principe du package mais je vais peut-être faire une réelle doc écrite pour mieux l'expliquer. Même si il y a de grandes chances que seul moi s'en serve...

Merci en tout cas pour le conseil, je n'y aurais pas pensé

Ps : J'ai fait le package et la modification, ca fonctionne comme il faut