Bonjour à tous,
Est ce que certains d’entre vous utilise Isardb sur un de leurs projets ? J’ai fait la MAJ de Flutter 3.24.3 et surtout fait la MAJ d’android Studio. En utilisant l’AGP android assistant sur le projet pour MAJ l’Android Gradle Plugin de la version 7.4 vers Android Gradle Plugin vers la version 8.6.1, Isar db 3.0.0+1 ne semble pas prendre en compte les versions au delà de Android Gradle au dela 7.4
De plus en regardand les package qui sont à mettre à jour flutter pub outdated
, il semblerait que cetrains soient bloqués à des versions passées. Je ne suis pas sur que ce soit lié mais je me poser la question.
Est ce que certains d’entre vous ont eu ce problème et y ont trouvé une solution ? Ou quelle est la bonne pratique dans ce cas là ?
Showing outdated packages.
[*] indicates versions that are not the latest available.
Package Name Current Upgradable Resolvable Latest
direct dependencies: all up-to-date.
dev_dependencies: all up-to-date.
transitive dependencies:
collection *1.18.0 *1.18.0 *1.18.0 1.19.0
http_parser *4.0.2 *4.0.2 *4.0.2 4.1.0
js *0.6.7 *0.6.7 *0.6.7 0.7.1
material_color_utilities *0.11.1 *0.11.1 *0.11.1 0.12.0
meta *1.15.0 *1.15.0 *1.15.0 1.16.0
string_scanner *1.2.0 *1.2.0 *1.2.0 1.3.0
transitive dev_dependencies:
_fe_analyzer_shared *61.0.0 *61.0.0 *61.0.0 74.0.0
analyzer *5.13.0 *5.13.0 *5.13.0 6.9.0
dart_style *2.3.2 *2.3.2 *2.3.2 2.3.7
leak_tracker *10.0.5 *10.0.5 *10.0.5 10.0.7
leak_tracker_flutter_testing *3.0.5 *3.0.5 *3.0.5 3.0.8
shelf *1.4.1 *1.4.1 *1.4.1 1.4.2
test_api *0.7.2 *0.7.2 *0.7.2 0.7.3
all dependencies are up-to-date.
@mbritto je sais que tu utilises Isar sur certains de tes projets (car c’est toi qui me l’a conseillé ). As tu ce problème également ? Je pense que le projet n’est plus maintenu.
Effectivement j’utilise Isar et je suis d’accord avec toi : il va falloir le remplacer car il n’est plus maintenu. J’espère que tu as suivi mes recommandations pour isoler tes dépendances
La bonne nouvelle c’est qu’un fork communautaire semble avoir pris le relais :
Je ne l’ai pas encore testé car la seule app en production que j’ai qui utilise Isar est l’app de Purple Giraffe en mode hors ligne ; et je me pose la question de basculer sur de simples fichiers json pour ces données. Mais si le fork communautaire fonctionne bien il peut me permettre de gagner du temps avant d’envisager de me séparer complètement de ma dépendance.
@Quentin : Tu avais vu ce fork ?
1 « J'aime »
Elle est plutôt bien isolée effectivement, mais le problème n’est quand même pas minime. Aussi isolée soit elle, la BDD c’est le coeur du réacteur de l’app : Un transfert complet vers une autre BDD plus main stream, même en locale, ne me parait pas anodin.
Quelles sont les bonnes pratiques : faire coexister les deux BDD Isar et son remplaçant sur une future MAJ et lancer un script de transfert au premier lancement ? Même avec assez peu de table, il doit falloir croiser fort les doigts pour ne rien louper… ce qui n’est pas facile il me semble.
Connais tu des méthodes plus robustes que ça pour opérer plus sereinement @mbritto ?
Effectivement migrer une base de données est toujours compliqué et il n’y a pas de recette miracle mais ton idée me semble bonne.
Sachant tout de même que le fork communautaire mentionné plus haut semble ne nécessiter aucune migration (à tester quand même).
A titre indicatif pour d’autres migrations qui elles pourraient être requises, voici une suite d’étapes possibles :
- Au lancement de la prochaine version, voir si la migration a été effectuée (tu peux utiliser un SharedPreferences pour ça par exemple)
- Si elle n’a pas été lancée, commencer la migration.
- Migration : lire chaque donnée dans la base source → l’écrire dans la base de destination
- A la fin de la migration, si tout s’est bien passé alors marquer la migration comme terminée (SharedPreferences par exemple)
- Tu peux choisir de conserver la base ancienne pour pouvoir y revenir en cas de pépin si tu as des retours comme quoi des données ont été oubliées. L’essentiel étant que tu utilises la nouvelle à partir de maintenant.
1 « J'aime »
Hello tout le monde,
Moi j’utilise Isar pour stocker tous les points de collectes de mes utilisateurs. Ca va m’impacter forcément.
Vous estimez à combien de temps le moment où il faudra basculer sur une autre solution ?
D’ailleurs si vous en avez une autre, je suis preneur
A vu de nez j’aurais dit Sqflite ou Drift : Label Flutter favorite et semble les plus populaire (pour éviter de se retrouver de nouveau dans cette situation malencontreuse :p)
Qu’en penses tu @mbritto, autres choses ?
J’ai vu également celle-ci en noSql. Pas de base de données a proprement parlé mais des objets.
Ca a l’air super simple à utiliser
2 « J'aime »
Je viens de lire que Realm était deprecated également (Si ma compréhension des choses est bonne) : Altlas + Realm 09/2024 à migrer avant 09/2025. Je comprends qu’il y a des similitudes avec objectbox (Bdd objet avec sync). Le côté sync n’est pas spécialement important dans mon cas.
Tu connais Realm @Tazooou ?
Quel casse tête le choix d’une db…
En tout cas bien vu pour objectbox. C’est en effet beaucoup plus simple au premier abord que de se lancer tête baissée dans le SQL. Certainement plus robuste qu’Isar pour la maintenabilité.
J’ai quand même l’impression que sur Flutter le choix est moins evident que sur les framework natifs (Swift et Kotlin). Qu’en pensez vous ?
J’étais déjà passé de Realm à Isaar … mais je ne me souviens plus bien pourquoi. J’ai le souvenir qu’on en avait discuté avec Maxime lors d’un coaching il y a un an
J’aime bien l’idée de stockage sous forme d’objet. C’est très facile au niveau des adapteurs de passer de l’objet réel à celui spécifique d’ObjectBox.
Je me pose également la question de supprimer mes sharedPreferences et de tout passer sur ce modèle qui me parait plus simple.
Pas de gestion de Json pour les objets un peu plus complexes et vitesse de lecture rapide.
J’attends l’avis de Maitre Kenobi avant de me lancer
1 « J'aime »
Les 3 projets ont l’air fonctionnels et maintenus mais Isaar et Realm l’étaient aussi. Je n’ai testé aucun des 3 donc rien de certain mais ObjectBox semble est le mieux documenté et il y a une équipe derrière au lieu d’une seule personne.
Dans tous les cas, isole bien cette dépendance et fait en sorte de pouvoir le remplacer plus tard si nécessaire.
1 « J'aime »