Core Data

Bonjour,

J'aimerais savoir si ceux qui codent des applications nécessitant de conserver des données utilisent Core Data?
Par exemple @muqaddar avec VinoCell, utilises-tu Core Data?

Et quand on utilise CoreData, comment ce passent les mises à jour de l'application? J'imagine qu'il y a une méthode pour éviter d'écraser la base de données? Et si la mise à jour modifie la structure de la base de données, que se passe-t-il?

la gestion des mises à jour, du point de vue de Core Data, est-elle identique pour les applications Mac et iOS?

Mots clés:

Réponses

  • Alors pour ma part, je l'utilise de manière intensive dans mes applications Mac pour stocker des scènes 3D (ma base contient plus de 400 classes Core Data)...

    Pour les mises à jour, il y a plusieurs systèmes de migration en fonction du type de modifications qui ont été apportées à la base. La plupart du temps je reste dans les clous de la migration "lightweight" qui est transparente et super simple à gérer. Pour les migrations lourdes, c'est un poil plus compliqué mais ça reste abordable. Du coté de l'utilisateur, une base à un ancien format est automatiquement convertie lors de sa première utilisation (la migration est un poil plus longue).

    Je ne l'utilise pas sur iOS, mais je suppose que c'est exactement les mêmes méthodes.

  • Merci pour ce témoignage rassurant :smile:

  • muqaddarmuqaddar Administrateur

    J'utilise SQLite, je n'ai jamais été attiré par CoreData.
    Je me sens + maître de mes requêtes avec SQLite (et ça me sert aussi pour la version Web d'être sur du standard SQL).

  • Merci @muqaddar , pas mal l'idée d'utiliser SQLite, d'autant que le framework semble se marier parfaitement avec SwiftUI contrairement à CoreData.
    Et concernant les mises à jour, aucun risque d'écraser les données?
    Autrefois j'utilisais PostgreSQL mais je n'ai jamais su comment l'utiliser quand une autre application l'utilisait également. J'avais rusé en découvrant le mot de passe et en utilisant la même base.
    Qu'en est-il de SQLite à ce niveau?

  • muqaddarmuqaddar Administrateur

    Tu peux utiliser GRDB popur SQLite:
    https://github.com/groue/GRDB.swift

    Il a un système de migration pour les données.

    (je ne l'utilise pas encore en prod)

  • @muqaddar a dit :
    Tu peux utiliser GRDB popur SQLite:
    https://github.com/groue/GRDB.swift

    Il a un système de migration pour les données.

    (je ne l'utilise pas encore en prod)

    OK mais je parlais de la mise à jour de l'application. Quand un de tes clients récupère une mise à jour depuis l'AppStore, les données ne sont évidemment pas écrasée. Est-ce automatique ou est-ce toi qui a programmé un truc pour sauvegarder/restaurer les données?

  • @Rocou a dit :

    @muqaddar a dit :
    Tu peux utiliser GRDB popur SQLite:
    https://github.com/groue/GRDB.swift

    Il a un système de migration pour les données.

    (je ne l'utilise pas encore en prod)

    OK mais je parlais de la mise à jour de l'application. Quand un de tes clients récupère une mise à jour depuis l'AppStore, les données ne sont évidemment pas écrasée. Est-ce automatique ou est-ce toi qui a programmé un truc pour sauvegarder/restaurer les données?

    Ça se fait tout seul.
    En bref, tu as un xcdatamodel, qui est ton modèle et qui peut évoluer, et tu as un fichier de database, qui lui n'est pas modifié lors des mises à jour de l'app, comme si tu avais un fichier de document, une photo sauvegardée dans ton app...

    CoreData est sympa en soit.
    Son gros point noir est si tu as besoin de faire du rapatriement de données via un service web et que tu as beaucoup de relations entre tes entités... C'est d'une galère (et cela créé des ralentissement)

  • CéroceCéroce Membre, Modérateur

    @Rocou a dit :smile:
    Et concernant les mises à jour, aucun risque d'écraser les données?

    GRDB a un système de migrations pour créer le schéma de la base de données et le modifier. Une migration est une suite d'opérations SQL: créer une table, ajouter des colonnes, copier des colonnes, changer le format d'une colonne, etc.
    C'est inspiré d'ActiveRecords (Ruby on Rails).

    Autrefois j'utilisais PostgreSQL mais je n'ai jamais su comment l'utiliser quand une autre application l'utilisait également. J'avais rusé en découvrant le mot de passe et en utilisant la même base.
    Qu'en est-il de SQLite à ce niveau?

    Une base de données SQLite n'est pas prévue pour être partagée entre plusieurs applis. C'est possible mais ce n'est pas du tout son esprit.

    À noter que que CoreData enregistre dans une base de données SQLite.

    @Larme a dit :
    CoreData est sympa en soit.

    CoreData est une horreur, même en Objective-C. La seule application que je trouve intéressante est pour un système de cache réseau, puisque dans ce cas, on n'a pas besoin de gérer les migrations.
    Pas mal de professionnels du développement iOS ont utilisé CoreData à un moment et ont fini par l'abandonner. C'est bien trop d'ennuis.

  • muqaddarmuqaddar Administrateur

    CoreData est une horreur, même en Objective-C. La seule application que je trouve intéressante est pour un système de cache réseau, puisque dans ce cas, on n'a pas besoin de gérer les migrations.
    Pas mal de professionnels du développement iOS ont utilisé CoreData à un moment et ont fini par l'abandonner. C'est bien trop d'ennuis.

    Et CoreData est très vieux, je suis étonné qu'il n'y ai jamais eu de successeur depuis si longtemps. Apple sortira aussi p-e un NoSQL local à sa sauce un jour.

    En partant sur du SQLite avec une librairie (GRDB ou autre), au moins tu as un standard.
    Si un jour tu changes de librairie, tu pourras au moins récupérer tes requêtes SQL.

  • @muqaddar a dit :
    Et CoreData est très vieux, je suis étonné qu'il n'y ai jamais eu de successeur depuis si longtemps. Apple sortira aussi p-e un NoSQL local à sa sauce un jour.

    Tu as raison... Il y a d'ailleurs des signes de laisser-aller évident : la visualisation des classes Core Data en graphe visuel a disparu des dernières versions d'Xcode.

  • muqaddarmuqaddar Administrateur

    @klog a dit :

    @muqaddar a dit :
    Et CoreData est très vieux, je suis étonné qu'il n'y ai jamais eu de successeur depuis si longtemps. Apple sortira aussi p-e un NoSQL local à sa sauce un jour.

    Tu as raison... Il y a d'ailleurs des signes de laisser-aller évident : la visualisation des classes Core Data en graphe visuel a disparu des dernières versions d'Xcode.

    Dans tous les cas, je reste assez friand du SQL, surtout dans les apps avec beaucoup, beaucoup de relations.
    Mais toutes les apps sont différentes.

  • @Céroce a dit :

    @Larme a dit :
    CoreData est sympa en soit.

    CoreData est une horreur, même en Objective-C.

    Tant que tu fais du simple, c'est sympa je trouve. Y'a des concepts à avoir évidemment, mais ça reste faisable. Et cela semble pas bien intégré à SwiftUI, et y'a CloudKit, et c'est donc du 100% Apple, pas besoin d'un service tiers (même si CloudKit semble limité en terme de query possibles)
    Mais sinon, oui, cela a ses limites plus c'est complexe.

Connectez-vous ou Inscrivez-vous pour répondre.