Baserow - Action Mettre à jour la ligne #1645

monikakuster publié le 22 octobre 2024

Implémentez l'action Mettre à jour la ligne pour le composant Baserow pour permettre aux utilisateurs de modifier des lignes spécifiques dans une table de leur base de données Baserow.

Propriétés de l'action :

• identifiant de la table - identifiant de la table pour laquelle vous souhaitez mettre à jour une ligne
• ID de ligne - identifiant de la ligne que vous souhaitez mettre à jour
• user_field_names - Un booléen indiquant si les noms de champs renvoyés par ce point de terminaison doivent être les noms réels des champs
• champs - une carte des champs et leurs nouvelles valeurs pour la table. Cette propriété spécifie les données à mettre à jour dans la ligne, permettant aux utilisateurs de modifier plusieurs champs en une seule opération.

Sortie :

• row - objet de ligne mis à jour contenant tous les champs de données et valeurs associés à la ligne dans la table spécifiée

Référence de la documentation : https://baserow.io/api-docs

</div>
<div class="gh-btn-container"><a class="gh-btn" href="https://github.com/bytechefhq/bytechef/issues/1645">View on GitHub</a></div>

Copier après la connexion

J'avais très peu utilisé Java avant de m'inscrire à ce numéro. Je n'avais réalisé que de petits programmes JavaFX dans le cadre d'un cours scolaire, mais je voulais en savoir plus. J'en avais appris un peu pendant mon temps libre, j'avais donc un certain niveau de familiarité avec des concepts tels que les packages, les modificateurs d'accès, les dépendances et Gradle, qui est l'outil de construction utilisé par le projet. Les connaître a définitivement rendu la participation à ce projet beaucoup moins intimidante. J'ai compris la structure du projet parce que j'avais appris comment les projets Gradle se composent de sous-projets et de sous-packages, chacun avec des configurations de construction différentes.

Ma camarade de classe Arina a remarqué que nous travaillions toutes les deux sur le même projet, et elle a eu la gentillesse de me donner quelques indications en créant un lien vers la documentation du développeur pour l'ajout d'un composant, et vers une action qui avait déjà été définie pour le composant, ce qui signifiait que je n'avais pas besoin de parcourir moi-même le référentiel pour trouver les fichiers/répertoires pertinents. Mais si je devais le faire, j'aurais utilisé git grep, la recherche de code de GitHub ou la recherche d'IntelliJ. J'ai utilisé git blâme pour vérifier l'historique du composant sur lequel j'allais travailler et j'ai vu que tout avait été développé en un seul commit.

Les documents contribuant au projet étaient très faciles à suivre avec des instructions détaillées présentées étape par étape. Mais le projet semblait très jeune - j'ai remarqué quelques fichiers README qui disaient simplement // TODO.

J'ai essayé de compiler et d'exécuter le programme avant d'apporter mes modifications pour voir comment il fonctionnait, mais ce fut un processus difficile. Voici un aperçu des notes que j'ai prises :

Une fois la compilation terminée (ce qui a pris plus d'une heure), je l'ai exécuté pour pouvoir vérifier le composant existant. J'ai essayé de créer un compte pour utiliser le client mais cela ne me le permettait pas, alors je suis retourné au document de contribution et j'ai découvert qu'il était livré avec un compte administrateur qui peut être utilisé pour le développement, qui, je pense, est créé lorsque vous exécutez Docker. -composer.

Une fois connecté, j'ai essayé de créer un composant Baserow, mais le client était un peu lent donc j'ai accidentellement fait un duplicata. Lorsque j'ai essayé de le supprimer, le client s'est figé, j'ai donc appuyé sur Actualiser et j'ai commencé à recevoir des erreurs de serveur et le client a expiré. J'ai essayé de redémarrer le serveur et le client, mais cela prenait beaucoup de temps – il me semblait que cela allait encore prendre une heure. Après avoir attendu environ 16 minutes, j'ai arrêté la soirée et j'ai décidé d'y travailler plus tard.

4 jours plus tard

Je redoutais de revenir sur ce projet et de devoir gérer une heure de compilation, mais avec le Hacktoberfest qui touche à sa fin, je n'avais pas vraiment le choix. Alors imaginez ma surprise lorsque le projet s'est construit sans erreur et a été opérationnel en moins de cinq minutes. Qu'est-ce qui a changé ? Je n'en ai aucune idée.

J'ai donc sauté sur le client et trouvé le composant Baserow.

Figure - Le composant Baserow et les actions existantes sur celui-ci

Pour ajouter l'action Créer une ligne, je devais consulter la documentation de l'API Baserow, qui m'était liée par le responsable. J'ai dû créer un compte Baserow pour consulter les documents, ce qui m'a semblé un peu étrange, mais ce n'était pas grave non plus.

J'ai donc testé l'action existante, "Créer une ligne", et j'ai rencontré un bug où la page entière se transformait en message d'erreur. Je pensais avoir entré une valeur inattendue, mais j'ai découvert plus tard que ce bug était déjà suivi par un problème distinct sans rapport avec le mien.

Lors d'une tentative de test ultérieure, l'action Créer une ligne a réussi. J'ai donc décidé que ce serait un bon candidat à étudier pour essayer de comprendre comment les actions sont créées. J'ai suivi en croisant les références au problème, à l'action existante et aux documents contributeurs.

J'ai appris que les actions étaient créées en définissant les paramètres d'entrée requis, le schéma de sortie et une méthode qui définissait le processus réel effectué par l'action.

Dans l'action Créer une ligne, j'ai vu qu'il y avait une méthode pour obtenir les champs d'une ligne du tableau, qui était utilisée pour définir les paramètres d'entrée. J'ai réalisé que je pouvais l'utiliser dans mon action, mais il a été nommé comme s'il était uniquement destiné à être utilisé pour l'action Créer une ligne. J'ai pensé que c'était logique de l'utiliser, alors je l'ai utilisé et j'ai décidé d'en informer les responsables.

En lisant la documentation de l'API Baserow, j'ai appris que pour mettre à jour une ligne, vous utilisez une méthode HTTP appelée "PATCH", dont je ne connaissais même pas l'existence. Un PATCH est comme un PUT mais au lieu de remplacer la ressource il la modifie partiellement. Des trucs intéressants.

J'ai donc pu écrire mon action et j'ai pu extraire à peu près tout le code de l'action existante. Je n'ai eu qu'à apporter de légers ajustements aux paramètres acceptés (j'ai ajouté un ID de ligne pour identifier la ligne à mettre à jour), au schéma de sortie et à la méthode qu'il a appelée (j'ai modifié le point de terminaison et la méthode HTTP). Pour autoriser l'ID de ligne, j'ai dû ajouter une constante à un fichier dans le sous-répertoire constant/ qui contenait toutes les constantes liées au composant Baserow.

J'ai remarqué que tous les fichiers de code source existants avaient un en-tête de licence, alors je l'ai également copié dans le mien. J'ai organisé mes importations, formaté mon code, et il était temps de le tester manuellement.

À ce stade, j'ai remarqué que la description de l'action Créer une ligne (celle qui existait déjà) était fausse - elle disait qu'elle créait une ligne dans un exemple de base de données dans Baserow à laquelle elle faisait référence par son nom au lieu de simplement dire que vous pouvez créer une rangée. J'ai pris note de le mentionner également aux responsables :

Figure - Description incorrecte du composant Créer une ligne

Mon action est apparue chez le client et visuellement tout avait l'air bien :

Le titre et la description sont apparus :

Les propriétés (c'est-à-dire les paramètres d'entrée) sont apparues :

Le workflow s'est exécuté avec succès et j'ai reçu une réponse positive :

Et le tableau a été mis à jour dans mon compte Baserow :

J'étais satisfait de mes modifications, alors j'ai continué et exécuté le formateur et les tests, mais les tests ont échoué, car l'un des tests s'attendait à ce que le composant Baserow n'ait qu'une seule action dessus. J'ai mis à jour le test pour s'adapter à ma nouvelle action et exécuté un script qui générait automatiquement la documentation pour le composant. En réexécutant les tests, ils ont réussi, mais j'ai quand même dû ajouter un test unitaire pour mon action. J'ai regardé le test unitaire du composant existant et je me suis laissé perplexe. J'ai décidé que j'avais fait des progrès décents, alors j'ai arrêté, j'ai ouvert un brouillon de PR et j'ai informé le responsable des problèmes que j'avais remarqués.

Le lendemain

Même si le test existant avait l'air effrayant, je n'avais pas vraiment d'autre choix que d'en ajouter un pour mon action aussi, alors je suis revenu en arrière et j'ai essayé de comprendre ce qui se passait dans le test existant. J'ai regardé un peu les bibliothèques de tests utilisées - JUnit Jupiter et Mockito. J'ai essayé de le décomposer petit à petit et j'ai utilisé un LLM pour m'aider à comprendre ce qui se passait sur chaque ligne. Mais pour être honnête, je n’avais encore qu’une vague compréhension de ce qui se passait. Je savais que je me moquais de l'API Baserow et que j'y appelais la méthode de mon action, mais c'était l'étendue de ma compréhension.

Apparemment, c'était assez bien. J'ai marqué mon PR prêt à être révisé et le responsable a accepté mes modifications ! Ils ont fourni des commentaires - j'ai oublié de suivre certaines parties du flux de contribution même si je les avais lues. Pour la prochaine fois, je devrais consulter les documents de contribution avant de créer la pull request.

Action Créer une ligne de mise à jour pour le composant Baserow #1656

ouday-rana publié le 29 octobre 2024

Description

Corrections #1645

Type de changement

• Nouvelle fonctionnalité (changement ininterrompu qui ajoute des fonctionnalités)
• Ce changement nécessite une mise à jour de la documentation

Comment cela a-t-il été testé ?

• Testé avec le test de définition BaserowComponentHandler, qui a été mis à jour pour s'adapter à la nouvelle action.
• Action testée manuellement via le client :

Liste de contrôle :

• [x] Mon code suit les directives de style de ce projet
• [x] J'ai effectué une auto-révision de mon propre code
• [ ] J'ai commenté mon code, notamment dans les zones difficiles à comprendre
  • Aucun commentaire n'est jugé nécessaire puisque l'action existante n'inclut pas non plus de commentaires
• [x] J'ai apporté les modifications correspondantes à la documentation
• [x] Mes modifications ne génèrent aucun nouvel avertissement
• [x] J'ai ajouté des tests qui prouvent que mon correctif est efficace ou que ma fonctionnalité fonctionne
• [x] Les tests unitaires nouveaux et existants réussissent localement avec mes modifications

Voir sur GitHub

J'ai trouvé que la configuration initiale et l'écriture du test étaient les parties les plus intimidantes de ce problème. En fait, l’ajout de la fonctionnalité était un jeu d’enfant en comparaison. Mais ce que j'ai trouvé vraiment cool dans ce problème, c'est que j'avais pu contribuer à un projet dans un langage que je ne connaissais pas très bien, grâce à leur documentation bien entretenue et à leur code facile à comprendre.

Et c'était mon dernier PR pour le Hacktoberfest 2024 ! Article récapitulatif à venir !