Précédent   Forum des professionnels en informatique > Logiciels > Solutions d'entreprise > Business Intelligence > ETL > Talend
Talend Forum d'entraide sur Talend (Talend Open Studio, ...). Avant de poster --> FAQ Talend, Tutoriels Talend
Partagez cette discussion sur d'autres réseaux sociaux : Viadeo Twitter Google Facebook Digg Delicious MySpace Yahoo
Réponse Proposer ce sujet en actualité
 
Outils de la discussion
Publicité
'
Vieux 24/06/2011, 06h25   #1
Membre régulier
 
Inscription : mai 2007
Messages : 173
Détails du profil
Informations personnelles :
Âge : 42
Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

Informations forums :
Inscription : mai 2007
Messages : 173
Points : 70
Points : 70
Par défaut Postgresql : pb de select après update

Bonjour,

J'effectue un chargement d'un fichier avec tos dans une base postgres.
Ce chargement insert d'abord dans une table puis dans une autre.
Les données insérées dans ma deuxième table sont liées aux données insérées dans la première (bref une association toute bête)
Pour ce faire :
1/ j'insère dans ma première table (tPostgresqlOutput)
2/ je recherche l'id de la donnée insérée par un select (tPostgresqlInput)
3/ je jointure l'id a mon flux de données (tMap)
4/ j'insert dans ma deuxième table avec l'id qui va bien.
A notre que je réutilise la même connexion pour les 4 étapes. Ma connexion est en autocommit.

Mon problème et que je n'arrive pas a résoudre l'id en étape 2 car la donnée insérée n'est pas trouvée. Du coup je ne peux insérer dans ma deuxième table.
Par contre si je relance mon job, l'insertion 4 marche a la deuxième itération.

En clair, le sélect ne vois pas l'insert qui viens juste d'être insèré. comme si cela était fait dans des connexions différentes non commitées.

Cette problématique étant Classique, je passe sans doute a coté d'un truc évident. Cela serait sans doute plus simple de récupérer l'id directement a l'insert mais je n'ai pas trouve comment faire cela.

Merci de vos eclairages
pdelorme est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 24/06/2011, 14h10   #2
Membre habitué
 
Homme Nicolas Vandenbergue
Conseil - Consultant en systèmes d'information
Inscription : janvier 2011
Messages : 88
Détails du profil
Informations personnelles :
Nom : Homme Nicolas Vandenbergue
Localisation : France, Maine et Loire (Pays de la Loire)

Informations professionnelles :
Activité : Conseil - Consultant en systèmes d'information
Secteur : Conseil

Informations forums :
Inscription : janvier 2011
Messages : 88
Points : 112
Points : 112
Bonjour,

Nous avons eu la même problématique, cf.
http://www.developpez.net/forums/d10...uto-increment/

Nous n'avons pas trouvé de meilleur moyen que la procédure stockée.

Je serai très intéressé par de meilleures réponses.
NicolasTT est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 24/06/2011, 19h35   #3
Membre régulier
 
Inscription : mai 2007
Messages : 173
Détails du profil
Informations personnelles :
Âge : 42
Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

Informations forums :
Inscription : mai 2007
Messages : 173
Points : 70
Points : 70
Mon problème est un peut différent dans le sens que j'arrive "en théorie" a récupérer l'id du row insèré (sans passer par tLastInsertedId mais en recherchant l'id dans l'étape suivante de mon flux... ) le problème est qu'il semble que le sélect ne vois pas l'insert qui viens d'avoir lieu.

En clair si j'insert X dans la table A et que je sélect id de la table A where X immédiatement apres, la ligne n'est pas trouvée. Par contre si je fait sélect id de A where X dans un autre job, je trouve ma ligne...
pdelorme est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 26/06/2011, 16h51   #4
Membre régulier
 
Inscription : mai 2007
Messages : 173
Détails du profil
Informations personnelles :
Âge : 42
Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

Informations forums :
Inscription : mai 2007
Messages : 173
Points : 70
Points : 70
En fait, il semble que tous les tPosgresqlInput soient chargés au démarrage de mon flux.... du coup les données insérées dans mon process ne sont pas vu dans mes maps...
comme on le vois sur le screenshot, la table parts est chargé avant que TMap_7 n'ai eu le loisir d'insérer dans la table parts

La question est : comment faire pour que les tPostgresInput ne soient chargé que lors de l'execution du tMap_3
Images attachées
Type de fichier : png Capture-1.png (43,6 Ko, 9 affichages)
pdelorme est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 04/07/2011, 22h00   #5
Rédacteur/Modérateur
 
Avatar de CyberChouan
 
Homme Benoît Courtine
Directeur technique
Inscription : janvier 2007
Messages : 2 744
Détails du profil
Informations personnelles :
Nom : Homme Benoît Courtine
Âge : 29
Localisation : France, Paris (Île de France)

Informations professionnelles :
Activité : Directeur technique
Secteur : High Tech - Produits et services télécom et Internet

Informations forums :
Inscription : janvier 2007
Messages : 2 744
Points : 4 202
Points : 4 202
Envoyer un message via MSN à CyberChouan
Un lien de type "onSubjobOK" entre l'insertion et la lecture devrait garantir que le second tPostgreSQLInput sera bien exécuté après l'insertion de la ligne, et donc qu'il récupérera le bon ID.
__________________
Avant de poster, pensez à regarder la FAQ, les tutoriaux, la Javadoc (de la JRE que vous utilisez) et à faire une recherche
Je ne réponds pas aux questions techniques par MP: les forums sont faits pour ça
Mes articles et tutoriaux & Mon blog informatique
CyberChouan est déconnecté   Envoyer un message privé Réponse avec citation 00
Réponse Proposer ce sujet en actualité
Outils de la discussion



Fuseau horaire GMT +2. Il est actuellement 01h42.


 
 
 
 
Partenaires

Hébergement Web