Passage d'entitie selection en paramètre de process

Pourquoi cela ne marche pas ?

dans la doc il est ecrit:

: Doc 4D

les paramètres de type Objet ou Collection sont passés par copie,
i.e. 4D créera une copie de l’objet ou de la collection dans le
process de destination, et non une référence.

Je reçois un objet vide dans mon process :?:

Réponse phrase suivante : « Si vous souhaitez passer un paramètre de type objet ou collection par référence, vous devez utiliser un objet ou une collection partagé(e) »
Ci-dessous, le paramètre $1 est vu comme Null alors que le $2 passe.
Mais avant même l’appel à Nouveau process, on constate que copier une entity sel n’a pas de sens.
<code 4D>
C_OBJET($1;$2)
C_OBJET($entSel_o)
C_OBJET($truc_o)
$method_t:=Nom méthode courante
Si (Nombre de paramètres=0)
$entSel_o:=ds.UNE_TABLE.query(“unChamp>:1”;1000)
ASSERT($entSel_o.length>0)
$copieEntSel_o:=OB Copier($entSel_o)
ASSERT($copieEntSel_o=Null)
$truc_o:=Créer objet(“heure”;Heure courante)
$pss_l:=Nouveau process($method_t;0;$method_t;$entSel_o;$truc_o)
Sinon
$entSel_o:=$1
$truc_o:=$2
ASSERT($entSel_o=Null)
ASSERT($truc_o.heure#Null)
Fin de si
</code 4D>

Je ne comprends pas ta réponse ?

4D analyse ce que contient l’objet pour le copier et le passer ou non au process ?

Je cherche à passer une sélection d’enregistrements à traiter dans un process ; Quelle est la meilleure façon de faire cela ?

Il y a aussi ça dans la doc :
https://doc.4d.com/4Dv17R3/4D/17-R3/Selections-d-entites.300-3961507.fe.html#3783366Note> : Une sélection d’entités est définie uniquement dans le process où elle a été créée. Vous ne pouvez pas, par exemple, stocker la référence d’une sélection d’entités dans une variable interprocess et l’utiliser dans un autre process.

C’est bon, je me suis dém… avec une collection NON partagée… :razz:

question subsidiaire: y a moyen de créer une collection contentant les n° d’enregistrement d’une selection directement ?

Actuellement, je bricole en convertissant le tableau entier long sur selection en collection mais si je partais directement en ORDA, on ferait comment pour récupérer les N° d’enregistrements dans la collection (c’est quoi le filtre) ?

: Manuel PIQUET

question subsidiaire: y a moyen de créer une collection contentant
les n° de l’enregistrement d’une selection directement ?
On le voit avec ds dans le debogueur, une entité n’a pas de numéro d’enregistrement. Il te faut peut être suivre l’avis de personnes sensées qui ont fait la remarque que ce n’était https://forums.4d.com/Post/FR/27391864/1/27391865#27392706pas une bonne idée>.

:oops: horreur, c’est moi qu’il ait dit :lol:

Non mais sans rigoler, qu’est-ce qui est conseillé de faire si j’ai besoin de faire un traitement en lot sur une selection d’enregistrements que je veux passer dans un nouveau process; comment je passe cette information pour faire ma boucle pour mon traitement dans mon nouveau process ?

Cela fonctionne en bricolant une collection de n° d’enregistrement à traiter mais y a t’il une solution plus élégante (en ORDA ?).

Je me réponds à moi-même (vivement le week-end :oops:)
Il suffit d’utiliser le PK de chaque enregistrement à traiter. :roll: et ça on peut facilement créer une collection de PK pour la passer en paramètre du nouveau process.

Bonjour Manuel, je bloque la dessus, peux-tu mettre un extrait de ta solution ? Merci :slight_smile:

Oula, Olivier tu me déterres un sujet de plus d’un an, je ne sais même plus de quoi cela parle. :sweat_smile:

C’est quoi ton problème, il faut créer une collection avec tes clés uniques (PK) puis tu peux boucler ensuite sur cette collection dans ton nouveau process pour faire ton traitement. Attention on parle bien de la clé unique PAS du numero de l’enregistrement !

Après, tu peux retrouver ton enregistrement avec la commande get()
ci-dessous un exemple (mais c’est pas celui dont je parlais, je le retrouve plus). Dans l’exemple, c’est pas une boucle sur une collection (ici Entity selection) mais c’est quasi la même chose

C_OBJET($Loopentity)
Pour chaque ($Loopentity;$ES_SelectionContrats)
	C_OBJET($entity;$status)
	C_TEXTE($pk)
	$pk:=$Loopentity.PK_UUID
	$entity:=ds.Contrat.get($pk)
	$entity.Statut:="A relancer"
	$status:=$entity.save(dk auto merge)
Fin de chaque 

2 remarques…
La première sur le “pour chaque (entité;selection)” de cet exemple. À l’optimisation orda près, ça se passe un peu trop comme un “tant que non fin de sel”, en termes de temps d’exécution - à ne pas faire en distant. Dans ce cas de mise à jour de statut, je ferais en classique, je pense : selection vers tableau/boucle sur tableau/tableau vers sélection.
La seconde sur le passage de sélection, j’ai une fois de plus lâché quelques gros mots hier devant un entitySelection.toCollection() qui peine à venir (pas vérifié, mais il parait que selection vers json est également assez lent). Là aussi je pense qu’un passage “classique” de sélection (sélection temporaire, tableau de numéros d’enregistrements) a des chances d’être plus efficace. Ou même un tableau des clés primaires suivi un chercher par tableau.

Arnaud, tu as parfaitement raison, mais il se trouve que ce bout de code (c’est qu’un exemple sorti de son contexte) est justement exécuté en local du serveur :stuck_out_tongue_closed_eyes: Mais en plus, je n’aime pas le passage par un tableau je ne connais pas la taille de la selection et je ne souhaite pas avoir un dépassement de capacité.

RROGNTUDJÛ
Puisqu’on te dit DE NE PAS UTILISER les numeros d’enregistrement M’ENFIN !!!

Après, oui, un tableau de clés primaire fait parfaitement l’affaire aussi…
C’était juste pour faire jeuns et utiliser des collections :grimacing:

Même sur le serveur, les opérations que je citais restent lentes, en particulier le ‘toCollection()’. Avec une pauvre table de moins de 500 enregistrements, je vois cette fenêtre s’afficher, 2 secondes au moins.

progression

Pour ce qui est du passage de numéros d'enregistrement par tableau, tu peux y aller, je pense. Je viens de faire ce test avec un table de ~6 millions d'enregistrements : j'en garde ~5 millions et je passe ça à un autre process via tableau : 2" en wan. Je ne vois pas trop comment dépasser la capacité d'un tableau que je viens de construire, d'ailleurs. Sinon il y a les ensembles, aussi : ça fait pas *djeun* mais c'est super efficace.

C’est pas le tableau en lui même que je n’aime pas, je n’utiliserais PAS les numéros d’enregistrements
T’as pas peur, @Sakowski.Christian (name dropping :wink:) va venir te tirer les oreilles.

Effectivement, c’est un peu complexe, j’aurais bien vu un Json stringify(ds.Contacts()) pour stocker la sélection dans un texte par exemple ou que les entitySélection puissent être des objets :slight_smile:
Merci en tout cas

Normalement, la sélection a été faite par une recherche. Perso je la refais dans le nouveau process en passant dans le process les variables à rechercher. mais c’est vrai que je n’ai jamais de recherches complexes. Dans le cas d’une table dont dépendent plusieurs tables, je passe en paramètre la rubrique caractéristique de cette table et dans le nouveau process une petite recherche de l’enregistrement de cette table, puis tout le reste se fait automatiquement avec les liens. J’avoue que c’est assez génial car il suffit de se souvenir des noms donnés aux liens.
Une autre solution , étant donné que la sélection est un objet, on peut le mettre dans une nouvelle variable “VARIANT” que l’on peut passer en paramètre. voir les nouveautés de la v18, mais là j’ai pas encore l’habitude

3 remarques :

  • on discute ici de passer une selection entre process (pas entre méthode)
  • cette selection comme vous l’avez dit est souvent complexe et non on ne peut pas toujours la restituer par des paramètres de recherche simples (imaginez une selection manuelle de l’utilisateur c’est quasi impossible à retranscrire par des paramètres de recherche.)
  • Une entité selection n’est PAS un simple objet (relire ce qui est dit en debut de ce fil (on ne peut pas passer une entité selection à un autre process car celle-ci n’est définie QUE dans le process initial !)

Bof, pourquoi en faire une question de principe ? Les ensembles aussi sont basés sur ces fameuses positions dans la table, les index 4D doivent l’être également, et ainsi de suite.
Un développeur m’avait dit autrefois « tu vois les chapitres sélection et ensemble : et bien tu ne les regardes même pas, tu les mets à la benne et tu ne travailles qu’avec des tableaux » : j’avais trouvé cette réflexion dénuée de bon sens. J’essaie autant que possible de développer avec 4D, pas contre 4D.
Dernièrement j’avais besoin de traiter une sélection avec une méthode EoS ; le faire par conversion de l’entity sélection en collection de clés fatigue mon client, mon serveur et prend bêtement du temps, je n’en vois pas l’intérêt. De même, pour imprimer une “moderne” entity selection, il faut bien en faire une “moche” sélection avec UTILISER ENTITY SELECTION, comme quoi même 4D fait avec le moche du moment que le moche fait le job.

C’est justement le problème en client-serveur (multi clients) que justement les risques que ta selection ne soit plus cohérente surviennent. En plus, c’est pas moi qui le dit c’est @Thomas_Maul ici :stuck_out_tongue_closed_eyes:

Bon, après chacun fait comme il veut hein…

Le raisonnement est parfaitement exact, en utilisant les numéros d’enregistrements on fait le pari que ça ne va pas bouger le temps de travailler avec, on peut donc perdre ce pari : c’est une affaire de probabilité. Le risque en question, c’est qu’un enregistrement soit supprimé entre temps et/ou qu’un ajouté vienne occuper un des “sièges vides” ; à part ça je ne vois pas. D’une part cet entre temps est supposé court, si on est sain d’esprit on n’utilise pas de sélection ou d’ensemble le temps d’un footing. D’autre part l’utilisation des clés primaire ne changera rien au fait qu’un des enregistrements a été supprimé.

Regarde les uuid : c’est un pari, on estime que la probabilité qu’une collision se produise est si faible qu’on peut la considérer comme nulle. J’ai beau le savoir, quand je grimpe dans une bagnole, un train ou un avion, je me demande toujours si l’informatique embarquée repose sur ce pari.