Coredata (2 questions) - Plus de 100 attributs - Mapping model ou pas
busterTheo
Membre
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:
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
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.
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.
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
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...
Pour changer la version du modèle, il faut ajouter du code comme :
… 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é.
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é...
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...
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...
https://developer.apple.com/documentation/foundation/filemanager/1415645-fileexists
Voilà du code que j'utilise pour remplacer la BDD sqlite pour un modèle Core Data :
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.
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.