Choisir son SGBD: création API pour SQLite


#1

Bonjour à tous,
Je suis un petit nouveau sur Gladys que je n’ai pas encore installé car avant j’aimerais faire quelques modifs (le cas échéant) pour que Gladys puissent fonctionner sur SQLite, beaucoup plus léger que MySQL, d’autant plus que j’ai d’autres bases de données SQLite qui tournent déjà sur mon Raspi. Bref pas trop envie d’avoir plusieurs SGBD sur mon Raspi.

Est-ce que quelqu’un peut me dire où se trouve le gestionnaire de la couche base de données ? Dans le core de Gladys je suppose mais j’ai beau chercher, je ne vois rien qui correspond à des fonctions de connexion, de fetch, etc… de SQL.
Merci d’avance.


#2

Je viens de m’apercevoir que tout le code SQL etait dans les différents module du Core.
Ce qui veut dire qu’il faudrait revoir l’architecture logiciel de Gladys pour:

  • transformer tout ce SQL en appel de service DAO
  • créer un service DAO pour MySQL
  • créer un service DAO pour SQLite
  • etc…
    et choisir sa base de données à l’installation (et donc le bon service DAO).
    Ce n’est pas une mince affaire…

#3

Hello!

Bienvenue sur le projet, et merci pour ton message :slight_smile:

Alors Gladys utilise “sails-mysql”, un adapter MySQL pour Sails.js ( le framework qui fait tourner Gladys)

Il doit y avoir un adapter “sails-sqlite” probablement.

En revanche tu as raison, les query SQL sont toutes écrites en prenant en compte qu’on utilise MySQL/MariaDB.

Je ne pense pas que développer Gladys sans prendre parti des spécificité de MySQL/MariaDB soit souhaitable pour le projet, on utilise quand même pas mal de fonctions/types de MySQL qui ne sont pas disponible sur SQLlite!

De manière générale, d’expérience, je suis rarement pour développer de façon DB-agnostique, chaque SGBD a ses spécificité et c’est dommage de ne pas en profiter! Tu loupes des optimisations.

Pourquoi es-tu tant que ça opposé à installer MariaDB sur ton Raspberry Pi ? c’est pas si lourd franchement… On parle pas d’un PostgreSQL là :slight_smile:


#4

Merci pour ta réponse Pierre-Gilles,
Je vais regarder ce que propose Sails en matière de connecteur SQLite.
Concernant la philosophie de développement, pour ma part, j’ai toujours pensé qu’il fallait si possible faire du générique plutôt que d’utiliser les spécificités d’un outil en particulier. L’inconvenient, c’est que ca demande un effort de developpement “générique”. L’avantage, c’est que le code n’est plus dépendant d’un outil (et donc de ses montées de version par exemple). Mais c’est un vaste débat.

Concernant le SQL de Gladys, j’ai fait des “grep” sur le code, et a priori je n’ai vu que des requêtes assez classiques. Ca pourrait peut être passer sur SQLite sans trop de réécriture.

SQLite est très peu gourmand en RAM puisque ce n’est pas un serveur, il ne tourne que lorsqu’une requête est exécuté. Il est également plus rapide que MySQL ou d’autres SGBD, puisqu’il y a un certain nombre de mécanisme qui ne sont pas implémentés, et qui de toute façon dans la plupart des projets ne sont pas utiles.
Autre avantage, tu pourrais embarquer la base SQLite dans ton projet Github puisqu’elle est entièrement contenu dans un seul fichier.

Enfin SQLite est principalement destinée au système embarqué, donc la plateforme Gladys/Raspi est tout à fait concerné.

Merci pour les infos en tout cas !
a+


#5

Pierre-Gilles, en regardant un peu plus en détail, je pense comprendre que tu utilises:

  • sails-mysql en utilisant le mécanisme ORM de Waterline, donc sans faire du SQL brut. C’est d’ailleurs comme ça que sont créées toutes les tables puisque je ne vois quasiment pas de CREATE TABLE.
  • et que tu fais un certains nombre de requêtes SQL brute en utilisant la méthode “query”
    Je me trompe ?
    Du coup, tu utilises déjà une approche d’abstraction de BD avec Waterline, donc c’est plus simple. Le but du jeu consiste à réécrire les appels à “query” en appel ORM pour faire de l’abstraction pure, mais dans un premier temps je pense que le connecteur “sails-sqlite3” peut être utilisé sans réécriture puisqu’il a lui aussi une méthode “query” et que le SQL est relativement classique.
    Je te tiens au courant.

#6

J’ai l’approche inverse pour ma part :smiley: Je ne suis vraiment pas fan des ORM, surtout quand tu travaille sur des machine aussi peu puissante que des Raspberry Pi. Les différences de performances sur des requêtes complexes se sentent vraiment, et on maitrise beaucoup moins les optimisations possibles.

Après c’est un vaste débat comme tu dis !

Au contraire c’est pour moi un inconvénient! L’avantage de MySQL est que les fichiers ne sont pas accessibles pour l’utilisateur, on peut écraser tranquillement les fichiers de Gladys entre chaque mise à jour sans pertes de données, toute la partie sécurité est gérée par MariaDB, c’est beaucoup plus simple pour le end-user. Et en RAM clairement Gladys tourne très bien à côté de MariaDB !

C’est justement mon objectif comme je disais! Le SQL brute me permet d’optimiser très finement les performances de chaque query, et c’est un travail sur lequel je porte beaucoup d’intérêt. Passer à un ORM n’est pas quelque chose de souhaitable pour le projet, c’est un choix personnel ! :slight_smile:

Je réitère ma demande, pourquoi vouloir faire migrer un projet entier utilisé par +30k utilisateurs sur un autre SGBD, quand actuellement tout fonctionne très bien ? :slight_smile: On a déjà une très très belle roadmap en termes de feature, beaucoup de développement en cours ( cf les issues Github => https://github.com/GladysProject/Gladys/issues ), et je vois peu d’avantages à rendre Gladys DB agnostique, ça rajoute même une complexité dont on peu peut-être se passer, non ?

Car chaque migration de base de donnée devra gérer tous les SGBD qui sont supportés par Gladys ( un peu lourd ), les tests unitaires devront être exécuté sur différents SGBD (si on décide de supporter MariaDB + SQLite, on double le temps d’exécution des tests), ça rajoute une lourdeur de développement pour peu d’avantages, non ?

Je comprends que toi qui ait que du SQLite tu sois un peu réticent à installer MariaDB, mais c’est un changement majeur qui à mon sens n’apporte pas grand chose pour les autres 30k utilisateurs…


#7

Je comprends très bien ton point de vue Pierre-Gilles, les choix personnels ne se discutent pas. D’autant plus que tout fonctionne à merveille et pour pas mal de monde, et que tu as fais un très beau produit. Je vais me débrouiller avec mon SQLite.
Si je peux apporter quelque chose au niveau de la roadmap ou des issues, n’hésites pas.
Peux-tu juste me dire dans quel fichiers sources se trouvent la création des tables stp ?
Merci d’avance.


#8

ça marche :slight_smile:

Le seul soucis c’est que si tu fais tourner ta version de Gladys modifiée, tu ne bénéficieras pas des mis à jours assez fréquente de Gladys, c’est dommage non ? ^^

Il faut pas hésiter, j’accepte avec plaisir les contributions :slight_smile: La plupart des issues Github flagguées (bug/enhancement) sont des todos qui sont à faire, donc si elles sont ouvertes et que tu aimerais contribuer, il ne faut pas hésiter à regarder, commenter sur l’issue pour dire que tu bosses dessus, et proposer une PR! La seule chose à faire c’est d’en parler avant, soit sur Github, soit sur le forum, histoire qu’on se coordonne bien :slight_smile:

Alors la création initiale des tables est faite automatiquement par sails.js en se basant sur le modèle => https://github.com/GladysProject/Gladys/tree/master/api/models ( un fichier = une table )

La création est faite en lançant le fichier :

node init.js 

Ou en lançant Gladys en mode développement ( avec la commande sails lift, voir la documentation de sails.js )

Ensuite, la migration de la base de donnée entre chaque version est effectuée dans ce fichier => https://github.com/GladysProject/Gladys/blob/master/api/core/task/task.dbMigration.js


#9

Ne t’inquietes pas pour les MAJ Gladys, je vais quand même pouvoir les suivre même avec ma version SQLite.
Ok, je regarderai les issues pour voir ce que je peux faire.
Merci pour les infos, je connais bien le JS et quelques librairies mais pas vraiment NodeJS et son ecosystème mais c’est l’occase de s’y mettre.
a+


#10

Salut Pierre-Gilles,
Je viens de lire ton article sur Gladys v4, c’est très prometteur.
Ravi de voir que tu as changé d’avis sur SQLite, il n’y a pour moi que des bénéfices à faire léger et efficace.

Bon courage !


#11

Vu que c’est une version majeure donc breaking, j’ai fais une passe sur toute la stack, c’était l’occasion de re-challenger l’utilisation de MariaDB :slight_smile:

Merci! :raised_hands: