Récemment, je suis tombé sur un problème où les données que j'importais dans mon application n'étaient pas mises à jour, même si je pensais avoir sûr d'avoir mon processus construit exactement comme prévu.

Commençons par un bref rappel du contexte. Comme je l'ai dit, j'importais des enregistrements dans mon application, disons environ 10,000 XNUMX enregistrements que je souhaitais ensuite mettre à jour et marquer comme « traités ».

J'ai donc créé mon importation à l'aide de services Web et mes données sont arrivées sans problème. J'ai ensuite créé un processus qui utilisait une limite de 1,000 XNUMX enregistrements à la fois et les mettait à jour. Une récupération à l'aide d'une limite vous permet de traiter un sous-ensemble des données de votre table, ce qui garantit que vous ne placez pas trop d'enregistrements en mémoire et que vous n'avez pas d'impact potentiel sur les performances de votre application.

De plus, j'utilisais un décalage ; un décalage vous permet d'indiquer où dans votre table vous souhaitez démarrer la récupération. Une fois que vous avez mis cela en place, vous pouvez itérer votre processus en augmentant votre limite pour être sûr de traiter tous vos enregistrements. Comme indiqué ci-dessous :

Alors, une explication basique de l'image ci-dessus :

• Créez un entier égal au nombre d’enregistrements auquel vous souhaitez « limiter » votre récupération (dans ce cas, 1,000 XNUMX)
• Créez un entier égal à votre décalage. Pour cet exemple, je dois commencer à 0, qui est bien sûr le premier enregistrement.
• Récupérez une liste de votre entité à l'aide d'une récupération personnalisée.
  • Définissez votre limite comme $Limit
  • Définissez votre décalage comme $Offset
• Parcourez votre liste et effectuez le processus que vous souhaitez
• Comptez le nombre d'entités que vous avez récupérées dans l'action de récupération
• Vérifiez si le nombre d'entités récupérées est égal à la limite que vous avez définie
  • Si oui (vrai), alors recommencez, il y en aura peut-être d'autres
  • Si non (faux), alors vous devez avoir atteint la fin de votre liste

Plutôt facile, non ? Malheureusement, j'ai oublié la chose la plus importante, à savoir intégrer un tri dans ma récupération.

Laissez-moi vous expliquer pourquoi cela est important. Vous verrez ci-dessous le résultat d'une récupération de « petits carrés » tels que définis dans mon microflow ci-dessus :

Disons simplement que l'image ci-dessus est un tableau avec 100 petits carrés. Je récupère une limite de 10, avec un décalage de 0. Les carrés mis en surbrillance sont ceux qui sont récupérés et traités. Une fois ce processus terminé, nous effectuons une autre récupération sur la base de données après avoir modifié le décalage au numéro de la récupération précédente (10).

Maintenant, mon ensemble d'enregistrements est récupéré, mais comme je n'ai pas défini d'ordre de tri, la récupération renvoie arbitrairement la liste sans ordre spécifique. Comme mon décalage est de 10, je commence par l'enregistrement 10, malheureusement, il peut s'agir d'enregistrements qui ont déjà été traités. L'image ci-dessous montre la deuxième liste récupérée et les enregistrements en surbrillance sont ceux que nous allons ensuite traiter :

L'image ci-dessous vous montre maintenant la récupération avec un tri appliqué. En appliquant le tri, nous voulons être sûrs d'utiliser l'attribut le plus unique possible. Cela nous aidera à être sûrs que la liste récupérée est toujours la même et que nous sommes sûrs de traiter chaque enregistrement de la table.

Parfois, il n'est pas judicieux d'implémenter un décalage. Imaginons cet exemple : les petits carrés sont soit blancs (non traités), soit bleus (traités). Je souhaite récupérer tous les enregistrements qui ne sont pas traités et les traiter. Dans mon action de récupération, j'applique une contrainte XPath de [Processed = false()].

Encore une fois, j'ai une table qui contient 100 enregistrements qui n'ont pas tous été traités comme vous pouvez le voir sur l'image ci-dessous. J'utilise ma limite de 10 et mon décalage de 0 pour obtenir les dix premiers enregistrements. Je vais ensuite traiter chacun de ces enregistrements :

J'ai traité les dix enregistrements et mon ensemble de données ressemble désormais à l'image ci-dessous. Si j'applique mon décalage modifié mais que je continue à utiliser ma contrainte XPath, mon processus ignorera les 10 premiers enregistrements de l'ensemble de données résultant, ce qui entraînera uniquement une mise à jour partielle.

D'après mon expérience, les exemples fournis dans cet article sont les exemples les plus courants de récupération et de traitement de limites et de décalages. Il existe d'autres situations dans lesquelles les données peuvent ou non être traitées en fonction des valeurs d'attribut ou d'autres raisons. Veillez toujours à utiliser un tri qui rendra la liste aussi statique que possible :

Donc, en résumé, lorsque vous avez affaire à la récupération de grands ensembles de données, vous devez :

• Utiliser des limites et des décalages
  • Les limites ne doivent pas être supérieures à 3,000 XNUMX, par exemple, pour minimiser l’impact sur la mémoire cache et les performances du système.
  • Le décalage doit être utilisé si votre contrainte de récupération n'entraîne pas de modification de l'ensemble d'enregistrements. Il doit également s'agir d'une variable et être défini à l'endroit de votre liste où vous souhaitez démarrer votre traitement.
• Utilisez le tri sur l'attribut le plus unique pour rendre votre récupération statique sur votre processus itératif

Comme pour tout processus que vous créez dans Mendix, veillez toujours à bien prendre en compte l'impact des choix et des actions que vous effectuez sur vos données. J'espère que le post précédent vous éclairera sur ce sujet et je vous souhaite à tous une bonne modélisation !