Coredata (2 questions) - Plus de 100 attributs - Mapping model ou pas

Bonjour,
j'ai une entité qui a 116 attibuts.
Xcode me met un warning.
Tout ça depuis longtemps, et j'ai décidé de résoudre ce pb.
Donc migration, mapping model ou pas...

J'ai donc maintenant mes 2 model, l'ancien avec 116 attributs, et le nouveau avec 96,
et du coup j'ai toujours le warning concernant l'ancien model.

Je me dis que j'ai fait tou ça pour rien...

Qu'en pensez-vous ?

Et d'autre part, je me demande aussi si de faire le mapping model est obligatoire, ou si je peux gérer moi-même dans mon code, les motifs.

Merci d'avance

Mots clés:

Réponses

  • PyrohPyroh Membre

    Une entité avec 116 attributs...
    Je pense qu'il doit y avoir un petit problème de conception. Et c'est là dessus qu'il faut travailler.
    Tu ne peux pas découper ton modèle ?

  • Merci pour ta réponse.
    Si, justement je l'ai découpé, mais comme l'app est en ligne, les users ont déjà enregistré dans l'ancien modèle.
    C'est pourquoi j'ai fait un second modèle et une migration, etc.

  • @busterTheo a dit :

    j'ai une entité qui a 116 attibuts.

    :o

  • busterTheobusterTheo Membre
    juin 2018 modifié #5

    Si j'ai bien compris :
    1- Si j'ai une entité avec plus de 100 attributs (et donc un warning Apple), je la découpe.
    2- Si mon app est déjà en ligne, et que je modifie mon modèle, je dois faire la migration (avec ou sans mapping model), et j'ai donc à présent 2 modèles.
    3- Si je suis dans le cas de 1- et 2-, j'aurais donc toujours mon warning (sur l'ancien modèle), et donc je suis coincé, du fait de mes erreurs de conceptions antérieures ?

    Je n'ai donc aucune solutions (mon app est déjà en ligne) ?

  • Ton application, c'est Muséum ? Si oui, tu n'as pas te préoccuper de migration de base. C'est problématique quand l'utilisateur peut ajouter ces propres données, mais là c'est une base interne utilisée exclusivement par ton application.

  • busterTheobusterTheo Membre
    juin 2018 modifié #7

    Merci Draken pour ta réponse.
    C'est justement le cas, l'utilisateur stocke tout un tas de données, et il ne devra pas les perdre lors d'une modification de la bdd.

    Ces données concernent des résultats de réglages (positions, inclinaisons, zooms, puis plein d'autres choses) sur plusieurs écrans associés à un "patient", et évidemment, il y a plusieurs patients.

  • Oups, désolé. J'étais fatigué hier soir et je t'ai confondu avec un autre développeur. Cela faisait un bon de temps que tu n'étais pas passé ici, pas depuis le changement de forum .. C'est pour ton application médicale de dentiste ?

  • d;-)
    no pb
    ça fait plaisir qu'on se souvienne de soi...
    oui - dentiste

  • Joanna CarterJoanna Carter Membre, Modérateur
    juin 2018 modifié #10

    Côté warning pour plus de 100 attributs, il ne faut qu'aller dans les Build Settings pour le projet, trouver "Suppress momc warnings for entities with more than 100 properties" et le changer de No à Yes.

    La limite pour SQLite est autour de 2000 colonnes mais, pour éviter de réduire la performance en Core Data, c'est "conseillé" de minimiser le nombre d'attributs ; c'est pas obligatoire.

    Mais, comme les autres, je me demanderais pourquoi tu l'as conçu avec un tel nombre d'attributs dans une seule entité ?

  • Ah merci Johanna.
    Mais mon app étant en ligne, si je voulais réduire le nombre d'attributs, avec un second modèle et une migration soft, l'ancien modèle étant toujours là (et donc avec plus d'attributs), la performance ne serait donc toujours pas augmentée.

    En fait le fait de faire un second modèle (avec migration.....), fait évidemment que l'ancien est toujours là. C'est ça qui m'ennuie.

    L'idéal serait bien sûr de refaire mon modèle plus proprement (sans migration), mais impossible, vu les précédents enregistrements des users qui ont l'ancienne app.

    Donc en gros, si j'ai bien compris, je ne fais rien. Je garde mon ancien modèle sans migration...

  • Joanna CarterJoanna Carter Membre, Modérateur

    Pour changer la version du modèle, il faut ajouter du code comme :

        let options = [NSMigratePersistentStoresAutomaticallyOption: true, NSInferMappingModelAutomaticallyOption: true]
    
        do
        {
          try psc.addPersistentStore(ofType: NSSQLiteStoreType, configurationName: nil, at: storeURL, options: options)
        }
        catch
        {
          fatalError("Error migrating store: \(error)")
        }
    

    … puis, ajouter une version au modèle original.

    Ou tu peux créer un deuxième modèle et, si l'utilisateur a déjà sauvegardé les données, il faut écrire du code pour transférer les données du premier modèle vers le deuxième, puis supprimer le premier.

  • "Pour changer la version du modèle..."
    Oui, j'ai déjà fait tou ça.

    "... puis supprimer le premier."
    Ah carrément, après ce transfert des données via mon code, je pourrais supprimer l'ancien modèle. Ouah.
    Bonne idée, je vais creuser cela. Risqué, mais plus propre à mon sens. J'aime pas trop avoir deux modèles.
    Sauf pour une bonne raison (Évolution de la bdd).

    Encore merci pour toutes ces précisions.

  • En fait, je ne vois pas comment transférer les données d'un modèle vers l'autre, si le premier est supprimé.

  • Joanna CarterJoanna Carter Membre, Modérateur

    En démarrant l'appli, il faut vérifier si le nouveau modèle existe. Si non, il faut : créer le créer, lire les données de l'ancien, les écrire au nouveau, puis supprimer l'ancien.

  • Heu, tout ça en code ?
    /
    vérifier si le nouveau modèle existe
    le créer
    puis supprimer l'ancien
    /

    Je comprend pas tout - Désolé...

  • Joanna CarterJoanna Carter Membre, Modérateur

    Oui, tout ça en code.

    En publiant ton appli sans avoir prévu les changements des données, tu n'as que deux choix : faire une migration avec un mapping model ou faire ce que j'ai proposé en code.

    Mais, je répète ; pourquoi tu t'inquiètes sur le nombre d'attributs ? Il ne faut que changer le warning dans le compilateur.

  • Bon, ok. Je laisse tomber, t'as raison. Merci d'insister d;-)

    Mais par curiosité, comment on vérifie si un modèle existe. J'ai rien vu à ce sujet...

  • @busterTheo a dit :

    Mais par curiosité, comment on vérifie si un modèle existe. J'ai rien vu à ce sujet...

    Ben c'est facile .. ton fichier CoreData a un nom, non ? Tu vérifies la présence du fichier correspondant dans le répertoire de ton application.

  • Merci pour ta réponse. J'avance d;-)
    ah ouais d'accord : "GuideEsthetique 2.xcdatamodel"
    Mais je ne sais pas détecter ce fichier, j'ai jamais fait ça.
    Je ne trouve rien là-dessus...

  • Joanna CarterJoanna Carter Membre, Modérateur

    Voilà du code que j'utilise pour remplacer la BDD sqlite pour un modèle Core Data :

          if applicationYear > existingYear
          {
            do
            {
              let oldFileURLs = try FileManager.default.contentsOfDirectory(at: documentURL, includingPropertiesForKeys: nil, options: .skipsHiddenFiles)
    
              for fileURL in oldFileURLs
              {
                try FileManager.default.removeItem(at: fileURL)
              }
    
              try FileManager.default.copyItem(at: sourceURL, to: storeURL)
    
              UserDefaults.standard.set(applicationYear, forKey: "applicationYear")
    
              UserDefaults.standard.synchronize()
            }
            catch
            {
              fatalError("Could not replace database: \(error)")
            }
          }
    
  • Ok, super. Merci pour vos réponses.
    Je ne connaissais pas du tout tout cela.
    Bonne fin de we.

  • Re-bonjour,
    comment puis-je mettre "Résolu" sur le nouveau forum : Pas trouvé.

    Merci.

  • Joanna CarterJoanna Carter Membre, Modérateur

    Tu edites le premier post en changeant le titre

  • Merci, c'est comme avant, en fait.

    Mais je ne peux pas éditer.
    Je ne peux éditer que le dernier post, et en plus le temps est limité. Il me reste 2 heures pour le dernier, et les autres pas d'édition possible.

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