Configuration des Données
Introduction
Avec Netuno, le développement des applications passe d'abord par la construction de la base de données, à travers la construction des formulaires et des champs.
Et lorsque l'on travaille en équipe ou qu'il faut transférer le développement de l'application vers un autre environnement, il est nécessaire de créer une sauvegarde de la base de données accompagnée du code.
Ainsi, sur la destination, il sera nécessaire de reconfigurer la base de données et l'application pourra alors être exécutée comme elle a été développée à son origine.
Le problème de ce processus est l'effort de toujours se rappeler de créer une nouvelle sauvegarde chaque fois qu'il y a une modification dans la base de données. Et plus il y a de personnes impliquées dans le développement et/ou plus il y a d'environnements pour publier l'application, plus ce processus devient compliqué.
Ainsi, Netuno, pour résoudre ce problème, apporte un système de setup des applications, où il génère automatiquement la structure de la base de données (schéma), et permet en plus de programmer manuellement le chargement des données initiales via des scripts supplémentaires.
Il permet également de changer le type de serveur de base de données en garantissant que le setup sera exécuté normalement et que l'application fonctionnera sans aucun problème. Cela signifie que l'application peut être développée avec H2DataBase et, avec les schémas générés automatiquement, pourra changer la connexion de la base de données de l'application vers PostgreSQL ou MariaDB. Lors de la première exécution de l'application sur la nouvelle base de données, tout sera reconstruit, indépendamment du changement du type de serveur de base de données.
Cela permet donc que la base de données soit complètement modifiée sans avoir d'impact sur le développement déjà réalisé.
Les fichiers de programmation du setup se trouvent dans le dossier de l'application :
server/setup
Configuration du Setup
Dans les configurations d'environnement des applications qui se trouvent dans :
/apps/MON_APP/config/_development.json/apps/MON_APP/config/_production.json
Vous pourrez manipuler le comportement du 'setup' via les configurations :
...
"setup": {
"enabled": true,
"schema": {
"auto_create": true,
"execution": true
},
"scripts": {
"execution": true
}
},
...
enabled: boolean > par défaut true
Définit si le setup est actif ou non, et ainsi active ou désactive, lors de la première exécution de l'application, l'exécution des opérations de setup des données.
schema.auto_create: boolean > par défaut true
Permet à Netuno de savoir s'il doit ou non générer les fichiers de schéma de base de données chaque fois qu'un formulaire ou champ est créé ou modifié.
schema.execution: boolean > par défaut true
Contrôle si le schéma doit être exécuté ou non pendant les opérations de setup réalisées lors de la première exécution de l'application.
scripts.execution: boolean > par défaut true
Active ou désactive l'exécution des scripts supplémentaires pendant les opérations de setup réalisées lors de la première exécution de l'application.
Schéma
Lors de la création ou de la modification des formulaires et champs dans l'interface web de Netuno, les fichiers de schéma seront générés dans le dossier setup de la manière suivante :
- JavaScript
- TypeScript
- Python
- Ruby
- Kotlin
- Groovy
server/setup/_schema-NOM_DU_FORMULAIRE.js
server/setup/_schema-NOM_DU_FORMULAIRE.ts
server/setup/_schema-NOM_DU_FORMULAIRE.py
server/setup/_schema-NOM_DU_FORMULAIRE.rb
server/setup/_schema-NOM_DU_FORMULAIRE.kts
server/setup/_schema-NOM_DU_FORMULAIRE.groovy
Où il y aura un fichier _schema-*** pour chaque formulaire existant dans l'application.
Ces fichiers ne doivent pas être modifiés manuellement car ils sont générés automatiquement par Netuno.
Ainsi, si vous modifiez le contenu de ces fichiers, lors d'une prochaine génération des schémas, ils seront automatiquement remplacés et les modifications effectuées directement dans les fichiers seront perdues.
Pour que la génération automatique du schéma de base de données soit exécutée, il faut s'assurer que la configuration schema.auto_create est active, et que le dossier setup existe dans le dossier server.
Scripts
Les scripts de code programmés sur mesure sont des fichiers situés dans le dossier setup qui ne commencent pas par _.
L'objectif principal de ces scripts est de charger les données en garantissant que la base de données contient les informations minimales nécessaires au bon fonctionnement de l'application.
Ainsi, lorsque l'application sera reconfigurée dans un autre environnement, elle sera automatiquement chargée avec les données initiales et prête à commencer son utilisation.
Pour effectuer ces opérations de chargement de données, vous devrez utiliser les fonctions de la ressource _db.
Les scripts sont exécutés après l'exécution des schémas par ordre alphanumérique du nom des fichiers
qui ne commencent pas par _.
Commencer le nom des fichiers par une séquence numérique est l'idéal pour définir l'ordre d'exécution, donc les scripts personnalisés sont exécutés dans l'ordre du nom des fichiers qui ne commencent pas par
_.
Insérer des données personnalisées
Et, pour éviter le travail de réaliser des requêtes dans la base de données afin de vérifier si l'insert
de données peut être effectué ou non, Netuno met à disposition la fonction insertIfNotExists.
Cette fonction vérifie si les données existent exactement telles qu'elles sont définies dans la base de données ; si elles n'existent pas, elle réalise leur création.
Un exemple de son utilisation sera de charger les champs Code et Nom du formulaire Type de Territoire, où le nom de la table est type_territoire et comporte les colonnes code et nom ; pour cela, il suffira de créer le fichier avec le contenu suivant :
- JavaScript
- TypeScript
- Python
- Ruby
- Kotlin
- Groovy
_db.insertIfNotExists("type_territoire", _val.map()
.set("code", "1001")
.set("nom", "Continental")
);
_db.insertIfNotExists("type_territoire", _val.map()
.set("code", "1002")
.set("nom", "Archipélagique")
);
_db.insertIfNotExists("type_territoire", _val.map()
.set("code", "2003")
.set("nom", "Maritime")
);
_db.insertIfNotExists("type_territoire", _val.map()
.set("code", "3004")
.set("nom", "Aérien")
);
_db.insertIfNotExists("type_territoire", _val.map()
.set("code", "1001")
.set("nom", "Continental")
);
_db.insertIfNotExists("type_territoire", _val.map()
.set("code", "1002")
.set("nom", "Archipélagique")
);
_db.insertIfNotExists("type_territoire", _val.map()
.set("code", "2003")
.set("nom", "Maritime")
);
_db.insertIfNotExists("type_territoire", _val.map()
.set("code", "3004")
.set("nom", "Aérien")
);
_db.insertIfNotExists("type_territoire", _val.map()
.set("code", "1001")
.set("nom", "Continental")
)
_db.insertIfNotExists("type_territoire", _val.map()
.set("code", "1002")
.set("nom", "Archipélagique")
)
_db.insertIfNotExists("type_territoire", _val.map()
.set("code", "2003")
.set("nom", "Maritime")
)
_db.insertIfNotExists("type_territoire", _val.map()
.set("code", "3004")
.set("nom", "Aérien")
)
_db.insertIfNotExists("type_territoire", _val.map()
.set("code", "1001")
.set("nom", "Continental")
)
_db.insertIfNotExists("type_territoire", _val.map()
.set("code", "1002")
.set("nom", "Archipélagique")
)
_db.insertIfNotExists("type_territoire", _val.map()
.set("code", "2003")
.set("nom", "Maritime")
)
_db.insertIfNotExists("type_territoire", _val.map()
.set("code", "3004")
.set("nom", "Aérien")
)
_db.insertIfNotExists("type_territoire", _val.map()
.set("code", "1001")
.set("nom", "Continental")
)
_db.insertIfNotExists("type_territoire", _val.map()
.set("code", "1002")
.set("nom", "Archipélagique")
)
_db.insertIfNotExists("type_territoire", _val.map()
.set("code", "2003")
.set("nom", "Maritime")
)
_db.insertIfNotExists("type_territoire", _val.map()
.set("code", "3004")
.set("nom", "Aérien")
)
_db.insertIfNotExists("type_territoire", _val.map()
.set("code", "1001")
.set("nom", "Continental")
)
_db.insertIfNotExists("type_territoire", _val.map()
.set("code", "1002")
.set("nom", "Archipélagique")
)
_db.insertIfNotExists("type_territoire", _val.map()
.set("code", "2003")
.set("nom", "Maritime")
)
_db.insertIfNotExists("type_territoire", _val.map()
.set("code", "3004")
.set("nom", "Aérien")
)
Cycle de traitement
Comme déjà expliqué, le setup n'est exécuté que lors de la première exécution de l'application.
Et l'ordre d'exécution est :
_start- exécute le fichier d'initialisation qui peut contenir tout type de programmation personnalisée :- JavaScript
- TypeScript
- Python
- Ruby
- Kotlin
- Groovy
MON_APP/server/setup/_start.js
MON_APP/server/setup/_start.ts
MON_APP/server/setup/_start.py
MON_APP/server/setup/_start.rb
MON_APP/server/setup/_start.kts
MON_APP/server/setup/_start.groovy
_cleanup- exécute la suppression de formulaires, rapports et leurs champs respectifs par programmation :- JavaScript
- TypeScript
- Python
- Ruby
- Kotlin
- Groovy
MON_APP/server/setup/_cleanup.js
MON_APP/server/setup/_cleanup.ts
MON_APP/server/setup/_cleanup.py
MON_APP/server/setup/_cleanup.rb
MON_APP/server/setup/_cleanup.kts
MON_APP/server/setup/_cleanup.groovy
_schema-*- exécute tous les scripts avec le préfixe _schema-, contient les commandes de création des formulaires, rapports et leurs champs respectifs :- JavaScript
- TypeScript
- Python
- Ruby
- Kotlin
- Groovy
MON_APP/server/setup/_schema-structure_auto_generee.jsMON_APP/server/setup/_schema-categorie.jsMON_APP/server/setup/_schema-produit.jsMON_APP/server/setup/_schema-client.js
MON_APP/server/setup/_schema-structure_auto_generee.tsMON_APP/server/setup/_schema-categorie.tsMON_APP/server/setup/_schema-produit.tsMON_APP/server/setup/_schema-client.ts
MON_APP/server/setup/_schema-structure_auto_generee.pyMON_APP/server/setup/_schema-categorie.pyMON_APP/server/setup/_schema-produit.pyMON_APP/server/setup/_schema-client.py
MON_APP/server/setup/_schema-structure_auto_generee.rbMON_APP/server/setup/_schema-categorie.rbMON_APP/server/setup/_schema-produit.rbMON_APP/server/setup/_schema-client.rb
MON_APP/server/setup/_schema-structure_auto_generee.ktsMON_APP/server/setup/_schema-categorie.ktsMON_APP/server/setup/_schema-produit.ktsMON_APP/server/setup/_schema-client.kts
MON_APP/server/setup/_schema-structure_auto_generee.groovyMON_APP/server/setup/_schema-categorie.groovyMON_APP/server/setup/_schema-produit.groovyMON_APP/server/setup/_schema-client.groovy
001-autres_scripts- exécute les fichiers de scripts programmés sur mesure, ce sont tous les fichiers qui ne commencent pas par_et qui contiendront probablement les inserts de données initiales nécessaires ou d'autres développements personnalisés, par exemple :- JavaScript
- TypeScript
- Python
- Ruby
- Kotlin
- Groovy
MON_APP/server/setup/001-insere_donnees_personnalisees.jsMON_APP/server/setup/002-categorie.jsMON_APP/server/setup/003-produit.jsMON_APP/server/setup/004-client.js
MON_APP/server/setup/001-insere_donnees_personnalisees.tsMON_APP/server/setup/002-categorie.tsMON_APP/server/setup/003-produit.tsMON_APP/server/setup/004-client.ts
MON_APP/server/setup/001-insere_donnees_personnalisees.pyMON_APP/server/setup/002-categorie.pyMON_APP/server/setup/003-produit.pyMON_APP/server/setup/004-client.py
MON_APP/server/setup/001-insere_donnees_personnalisees.rbMON_APP/server/setup/002-categorie.rbMON_APP/server/setup/003-produit.rbMON_APP/server/setup/004-client.rb
MON_APP/server/setup/001-insere_donnees_personnalisees.ktsMON_APP/server/setup/002-categorie.ktsMON_APP/server/setup/003-produit.ktsMON_APP/server/setup/004-client.kts
MON_APP/server/setup/001-insere_donnees_personnalisees.groovyMON_APP/server/setup/002-categorie.groovyMON_APP/server/setup/003-produit.groovyMON_APP/server/setup/004-client.groovy
- _end - exécute le fichier de finalisation qui peut contenir tout type de programmation personnalisée :
- JavaScript
- TypeScript
- Python
- Ruby
- Kotlin
- Groovy
MON_APP/server/setup/_end.js
MON_APP/server/setup/_end.ts
MON_APP/server/setup/_end.py
MON_APP/server/setup/_end.rb
MON_APP/server/setup/_end.kts
MON_APP/server/setup/_end.groovy
C'est-à-dire qu'il est permis de créer du code sur mesure dans les scripts start et end pour réaliser certaines opérations qui ont du sens à exécuter avant le setup ou même lorsqu'il est terminé.
Il convient de souligner que ce cycle de traitement est exécuté chaque fois que l'application est exécutée pour la première fois, c'est pourquoi il est nécessaire de garantir la vérification de l'existence des données avant de réaliser leur création.
Assurez-vous que les configurations d'environnement suivantes sont actives pour permettre l'exécution de ce
processus dans les fichiers MON_APP/config/_development.json ou MON_APP/config/_production.json selon
l'environnement :
-
Active ou désactive complètement l'exécution de toute opération de setup :
setup.enabled = true|false -
Active ou désactive l'exécution des _schemas- :
setup.schema.execution = true|false -
Active ou désactive l'exécution des scripts :
setup.scripts.execution = true|false
Nettoyage
Pour programmer la suppression de formulaires et de champs, nous devons utiliser le script _cleanup.js, ce qui garantit
que, dans tous les environnements qui synchronisent les fichiers du projet, lors de l'exécution du setup, la structure sera supprimée,
si elle existe.
Exemple du script de nettoyage :
- JavaScript
- TypeScript
- Python
- Ruby
- Kotlin
- Groovy
// Supprime le formulaire zone :
_form.dropIfExists("zone");
// Supprime le champ sous_aire_id du formulaire aire :
_form.dropFieldIfExists("aire", "sous_aire_id");
// Supprime le formulaire zone :
_form.dropIfExists("zone");
// Supprime le champ sous_aire_id du formulaire aire :
_form.dropFieldIfExists("aire", "sous_aire_id");
# Supprime le formulaire zone :
_form.dropIfExists("zone")
# Supprime le champ sous_aire_id du formulaire aire :
_form.dropFieldIfExists("aire", "sous_aire_id")
# Supprime le formulaire zone :
_form.dropIfExists("zone")
# Supprime le champ sous_aire_id du formulaire aire :
_form.dropFieldIfExists("aire", "sous_aire_id")
// Supprime le formulaire zone :
_form.dropIfExists("zone")
// Supprime le champ sous_aire_id du formulaire aire :
_form.dropFieldIfExists("aire", "sous_aire_id")
// Supprime le formulaire zone :
_form.dropIfExists("zone")
// Supprime le champ sous_aire_id du formulaire aire :
_form.dropFieldIfExists("aire", "sous_aire_id")
DBML
Chaque fois que Netuno exécute le setup des données, le fichier suivant est généré :
server/setup/_db-schema.dbml
C'est le fichier contenant toute la structure de données qui peut être utilisé avec l'Intelligence Artificielle.
Sur la base du contenu du DBML, l'Intelligence Artificielle comprend la structure de données et peut générer des requêtes SQL précises.
Essayez d'utiliser ce fichier en pièce jointe dans le prompt et demandez de générer des requêtes SQL complexes ; vous obtiendrez de bons résultats.
Conclusion
Le processus de setup des applications dans Netuno a comme principales fonctions :
- _schema- : génère automatiquement toute la structure de formulaires et rapports avec leurs champs respectifs, ce qui permet de garantir toute la cohérence de la structure de la base de données de l'application, principalement lorsque l'application est exécutée avec une nouvelle base de données vide.
- scripts : réaliser des opérations de base de données pour garantir que l'application contient les données obligatoires préalablement chargées chaque fois qu'elle est exécutée pour la première fois.
De cette manière, Netuno permet aux applications de fonctionner dans de nouveaux environnements, même si le type de base de données change, en garantissant le bon fonctionnement de l'application sans la nécessité de réaliser des sauvegardes et des restaurations des bases de données.
Permettant en outre que tout le code de configuration généré de manière automatique et manuelle soit versionné avec GIT, par exemple.