RELATE ONE (Charger sur lien) bientôt Threadsafe?

Bonjour est-ce que la commande CHARGER SUR LIEN va passer en (Threadsafe) préemptif ?
D’après la doc 17R3 elle ne l’est toujours pas (une des dernieres).

Il a beaucoup été question de Liens, mais en utilisant des liens manuels, cette commande me semble vraiment necessaire.

Ou alors est-il conseillé d’utiliser d’autres commandes ?
Si oui, lesquelles seraient plus optimisées pour cette tâche ?

D’avance merci.

: Luc STELL

Il a beaucoup été question de Liens, mais en utilisant des liens
manuels, cette commande me semble vraiment necessaire.
Ou alors est-il conseillé d’utiliser d’autres commandes ?
Salut Luc,
je ne sais pas à quelle syntaxe tu fais allusion, mais la première, CHARGER SUR LIEN (laTable), combinée à FIXER LIEN CHAMP, est un bijou d’optimisation de requêtes. Par exemple, si j’ai un enregistrement courant [ADHESION] dont je veux charger 3 “pères” et 1 “grand-père” :
[ADHESION]->[ETAB_DANS_CONTRAT]
[ADHESION]->[INDIVIDU]
[ADHESION]->[OPTION]->[CONTRAT]
… ce code le fait :
<code 4D>
FIXER LIEN CHAMP([ADHESION]FK_ETAB_DANS_CONTRAT;Automatique;Configuration structure)
FIXER LIEN CHAMP([ADHESION]FK_INDIVIDU;Automatique;Configuration structure)
FIXER LIEN CHAMP([ADHESION]FK_OPTION;Automatique;Configuration structure)
FIXER LIEN CHAMP([OPTION]FK_CONTRAT;Automatique;Configuration structure)
CHARGER SUR LIEN([ADHESION]) //charge 4 “pères” en une seule requête
</code 4D>
Je vois mal par quoi je pourrais remplacer une commande qui fait en une seule requête aussi bien que 4 CHERCHER. Ou alors passer à ORDA, mais c’est autre chose.

Quand à la seconde syntaxe avec un champ clé reportée, CHARGER SUR LIEN ([tableFils]FK_tablePere), je ne m’en suis jamais servi. Je ne vois pas trop ce qu’elle apporte de mieux qu’un CHERCHER([tablePere];[tablePere]PK=[tableFils]FK_tablePere).

Salut Arnaud et merci pour ta réponse,

cependant tu utilises aussi le CHARGER SUR LIEN.

Dans ce cas pour être en "préemptif, il faudrait passer par :
<code 4D>
FIXER LIEN CHAMP ([TABLEN]Cle_etrangere;automatique;Configuration structure)
chercher([MATABLE];[MATABLE]monchamp=“xxx”)
FIXER LIEN CHAMP ([TABLEN]Cle_etrangere;manuel;Configuration structure)

</code 4D>

3 instructions au lieu d’une, c’et pas vraiment top !
il faudrait aussi après le ‘Chercher’ vérifier qu’il y ait bien un enregistrement de trouvé…

Contexte : pour un serveur Web (e-commerce) j’ai pour beaucoup de tables, une table pendante pour les langues.
Ex : Table ART <— Table ART-LANG

Cela permet d’avoir autant de langues différentes que souhaitées par le client. (idem pour les categories, mode de paiement, livraisons, News, …)

Je travaille donc avec des enregistrements de tables ART_LANG et pour avoir les informations de la table parente (ART) j’utilise la commande CHARGER SUR LIEN quand c’est nécessaire uniquement.

Tout fonctionne correctement, mais je ne peux pas compiler en mode préemptif à cause de cette commande.

Je viens à l’instant de trouver une astuce en utilisant la commande CREER SUR LIEN qui elle, est en mode préemptif, et qui si je lis bien la documentation, fait la même chose que CHARGER SUR LIEN lorsque l’enregistrement parent à créer existe déjà (ce qui est toujours le cas chez moi).

Je vais tester, mais trouve cela très “Inélégant” d’un point de vue sémantique.

Il faudrait quand même que 4D nous dise si il y a une raison particulière pour que cette instruction ne soit pas mise en mode préemptif. C’est peut-être juste un oubli ?

Plusieurs réflexions…

cependant tu utilises aussi le CHARGER SUR LIEN.
Oui, mais (désolé si je me répète…) toujours avec table comme paramètre, jamais avec champ dont je n’ai pas compris l’intérêt. Je n’utilise CHARGER SUR LIEN que pour un cas, bien précis : charger en une seule fois plusieurs les pères vers lesquels mon enregistrement courant pointe avec des liens aller automatiques. Ton exemple de la table ART-LANG qui pointe sur ART est justement celui où je n’utiliserais pas CHARGER SUR LIEN, mais CHERCHER : ça me suffit puisqu’il n’y a qu’un enregistrement comme cible. Et ce sera préemptif comme tu le souhaites.

Dans ce cas pour être en "préemptif, il faudrait passer par […]
CHERCHER sait utiliser les liens mais ne fait aucune différence entre manuel et automatique : FIXER LIEN CHAMP ne lui fait ni chaud ni froid.

il faudrait aussi après le ‘Chercher’ vérifier qu’il y ait bien un
enregistrement de trouvé…[…]
[…]l’enregistrement parent à créer existe déjà (ce qui est toujours
le cas chez moi).[…]
Je viens à l’instant de trouver une astuce en utilisant la commande
CREER SUR LIEN
(j’assemble tout ça exprès, ça me semble contradictoire)
• soit tu es certain que ART_LANG, chez toi, a toujours un père ART, dans ce cas inutile de vérifier que CHERCHER l’a trouvé
• soit tu es méfiant et tu veux être sûr que ART existe et est trouvé : si(enregistrement trouves([ART])=1). Mais le faisais-tu avec CHARGER SUR LIEN ? Et si la réponse est “non”, pourquoi ferais tu après CHERCHER une vérification que tu jugeais inutile avec CHARGER SUR LIEN ?
• enfin, tu ne peux pas à la fois te dire qu’il est bon de vérifier que ART existe, tout en optant pour CREER SUR LIEN qui le créé automatiquement s’il n’est pas trouvé !

Bon, bref, moi je ferais chercher, sur ce coup.

Dans le fonds tu as sans doute raison.
A force de se focaliser sur le lien, on en oublie les autres possibilités.

Vendu, on va faire un test…

: Luc STELL

Il a beaucoup été question de Liens, mais en utilisant des liens
manuels, cette commande me semble vraiment necessaire.
Ou alors est-il conseillé d’utiliser d’autres commandes ?
Salut Luc,
je ne sais pas à quelle syntaxe tu fais allusion, mais la première, CHARGER SUR LIEN (laTable), combinée à FIXER LIEN CHAMP, est un bijou d’optimisation de requêtes. Par exemple, si j’ai un enregistrement courant [ADHESION] dont je veux charger 3 “pères” et 1 “grand-père” :
[ADHESION]->[ETAB_DANS_CONTRAT]
[ADHESION]->[INDIVIDU]
[ADHESION]->[OPTION]->[CONTRAT]
… ce code le fait :
<code 4D>
FIXER LIEN CHAMP([ADHESION]FK_ETAB_DANS_CONTRAT;Automatique;Configuration structure)
FIXER LIEN CHAMP([ADHESION]FK_INDIVIDU;Automatique;Configuration structure)
FIXER LIEN CHAMP([ADHESION]FK_OPTION;Automatique;Configuration structure)
FIXER LIEN CHAMP([OPTION]FK_CONTRAT;Automatique;Configuration structure)
CHARGER SUR LIEN([ADHESION]) //charge 4 “pères” en une seule requête
</code 4D>
Je vois mal par quoi je pourrais remplacer une commande qui fait en une seule requête aussi bien que 4 CHERCHER. Ou alors passer à ORDA, mais c’est autre chose.

Quand à la seconde syntaxe avec un champ clé reportée, CHARGER SUR LIEN ([tableFils]FK_tablePere), je ne m’en suis jamais servi. Je ne vois pas trop ce qu’elle apporte de mieux qu’un CHERCHER([tablePere];[tablePere]PK=[tableFils]FK_tablePere).

Salut Arnaud et merci pour ta réponse,

cependant tu utilises aussi le CHARGER SUR LIEN.

Dans ce cas pour être en "préemptif, il faudrait passer par :
<code 4D>
FIXER LIEN CHAMP ([TABLEN]Cle_etrangere;automatique;Configuration structure)
chercher([MATABLE];[MATABLE]monchamp=“xxx”)
FIXER LIEN CHAMP ([TABLEN]Cle_etrangere;manuel;Configuration structure)

</code 4D>

3 instructions au lieu d’une, c’et pas vraiment top !
il faudrait aussi après le ‘Chercher’ vérifier qu’il y ait bien un enregistrement de trouvé…

Contexte : pour un serveur Web (e-commerce) j’ai pour beaucoup de tables, une table pendante pour les langues.
Ex : Table ART <— Table ART-LANG

Cela permet d’avoir autant de langues différentes que souhaitées par le client. (idem pour les categories, mode de paiement, livraisons, News, …)

Je travaille donc avec des enregistrements de tables ART_LANG et pour avoir les informations de la table parente (ART) j’utilise la commande CHARGER SUR LIEN quand c’est nécessaire uniquement.

Tout fonctionne correctement, mais je ne peux pas compiler en mode préemptif à cause de cette commande.

Je viens à l’instant de trouver une astuce en utilisant la commande CREER SUR LIEN qui elle, est en mode préemptif, et qui si je lis bien la documentation, fait la même chose que CHARGER SUR LIEN lorsque l’enregistrement parent à créer existe déjà (ce qui est toujours le cas chez moi).

Je vais tester, mais trouve cela très “Inélégant” d’un point de vue sémantique.

Il faudrait quand même que 4D nous dise si il y a une raison particulière pour que cette instruction ne soit pas mise en mode préemptif. C’est peut-être juste un oubli ?

Plusieurs réflexions…

cependant tu utilises aussi le CHARGER SUR LIEN.
Oui, mais (désolé si je me répète…) toujours avec table comme paramètre, jamais avec champ dont je n’ai pas compris l’intérêt. Je n’utilise CHARGER SUR LIEN que pour un cas, bien précis : charger en une seule fois plusieurs les pères vers lesquels mon enregistrement courant pointe avec des liens aller automatiques. Ton exemple de la table ART-LANG qui pointe sur ART est justement celui où je n’utiliserais pas CHARGER SUR LIEN, mais CHERCHER : ça me suffit puisqu’il n’y a qu’un enregistrement comme cible. Et ce sera préemptif comme tu le souhaites.

Dans ce cas pour être en "préemptif, il faudrait passer par […]
CHERCHER sait utiliser les liens mais ne fait aucune différence entre manuel et automatique : FIXER LIEN CHAMP ne lui fait ni chaud ni froid.

il faudrait aussi après le ‘Chercher’ vérifier qu’il y ait bien un
enregistrement de trouvé…[…]
[…]l’enregistrement parent à créer existe déjà (ce qui est toujours
le cas chez moi).[…]
Je viens à l’instant de trouver une astuce en utilisant la commande
CREER SUR LIEN
(j’assemble tout ça exprès, ça me semble contradictoire)
• soit tu es certain que ART_LANG, chez toi, a toujours un père ART, dans ce cas inutile de vérifier que CHERCHER l’a trouvé
• soit tu es méfiant et tu veux être sûr que ART existe et est trouvé : si(enregistrement trouves([ART])=1). Mais le faisais-tu avec CHARGER SUR LIEN ? Et si la réponse est “non”, pourquoi ferais tu après CHERCHER une vérification que tu jugeais inutile avec CHARGER SUR LIEN ?
• enfin, tu ne peux pas à la fois te dire qu’il est bon de vérifier que ART existe, tout en optant pour CREER SUR LIEN qui le créé automatiquement s’il n’est pas trouvé !

Bon, bref, moi je ferais chercher, sur ce coup.

Dans le fonds tu as sans doute raison.
A force de se focaliser sur le lien, on en oublie les autres possibilités.

Vendu, on va faire un test…