[Résolu] NSManagedObject -> Copier un object sans sauvegarder
paoz
Membre
Bonjour à tous,
J'utilise Core Data dans mon application sans MagicalRecord, et je suis confronté à un problème avec plusieurs solutions possibles que je voudrais partager avec vous pour savoir quelle est la meilleure.
J'ai un objet qui s'appelle Product, et qui a des Subproducts. Tout ça fonctionne très bien. Après, j'ai voulu implémenter un Panier virtuel (Cart) pour permettre d'acheter les objets en question.
Mon panier virtuel contient des Products, avec les Subproducts séléctionnés pour chaque Product.
Le soucis que j'ai, c'est que quand j'ajoute un produit dans mon panier, c'est en réalité le vrai produit que j'ajoute puisque tout est pointeur en Objective C.
Du coup, quand dans mon panier j'énumère tous les sous produits que j'ai ajouté, je retrouve tous les sous-produits même ceux que j'ai pas ajouté. Logique!
Pour l'instant je contourne ça en vérifiant la quantité (si c'est 0 c'est que le sous-produit n'est pas dans le panier) mais c'est crado et à mon sens ce n'est pas du bon code.
Il y a plusieurs solutions à ce problème, et notamment de créer des objets à part entière pour le panier, en copiant le Product avec le seul sous-product choisi. Sauf que cette solution créé un véritable objet Product qui est après stocké dans le ManagedObjectContext ! Donc si j'énumère les objets (les Products) je me retrouve avec ceux du panier qui sont dupliqués.
Vu que j'ai créé les NSManagedObject, j'ai les fichiers .h correspondants (Product.h et Subproduct.h).
Je pourrais donc aussi créer les objets destinés à mon panier, sans passer par mon ManagedObjectContext. Cette solution est envisageable, mais je ne sais pas si c'est sale ou pas. Est-ce que c'est destiné à être utilisé de cette manière ou pas! Par exemple si je fais ça, alors quand j'écris
product.subproducts
Ca me retourne une belle exception, car je dois aussi allouer l'espace pour les sous-produits (d'où ma question, est-ce propre ou pas de faire comme ça).
Merci de vos remarques 
Réponses
Ton object Panier contiendrait alors directement ta liste de courses. Le fait que ce soit stocké dans ta base permettrait de commencer un panier et d'y revenir 2j plus tard même après être sorti de l'appli si tu ne veux pas terminer tes achats tout de suite. Et quand le panier est fini tu le transforme en commande et tu le supprimes de ton CorrData.
Autre solution, avoir un NSArray de NSManagedObjectIDs pour garder la liste de tes produits dans ton panier.
Salut Ali,
Je me suis peut-être mal exprimé, mais c'est exactement ce que j'ai fait. J'ai bien un objet Cart, relié avec une relation one-to-many à Product.
Le soucis provient du fait que si je copie un objet Product dans mon panier, c'est l'objet avec tous ses Subproducts que j'ajoute, et pas seulement un seul des Subproducts (que j'ai choisi d'ajouter !).
C'est plus clair maintenant ?
Pourquoi n'ajoutes-tu pas les subproduct au lieu des product ?
Bonjour,
"Qui a des" = une variable d'instance genre NSMutableArray ou une relationship (many-to-many) entre des entités Product et des entités Subproduct ?
Parce que Cart ---> Product ---> Subproduc.
J'ai créé mon data model de cette façon. Ce qui n'est pas illogique non plus à mon avis.
Mais ca ne change rien à mon problème.
One to many.
Un produit peut avoir un ou plusieurs sous-produits.
Minimum 1 sous-produit pour être logique.
Excuse-moi, mais il me semble que tu as fais un erreur de logique dans ton modèle ; pour trouver une solution, il faut te poser quelques questions.
1. Est-ce qu'un produit se compose des sous-produits?
2. Est-ce que les sous-produits sont optionnels ?
3. Peux-tu nous donner un exemple d'un produit et ses sous-produits ?
1 - Oui
2 - Non
3 - Produit : iPhone 5s
Sous-produit : Couleur Or, 64 Go
Donc dans mes listes, tu choisis d'abords le produit que tu veux, puis le sous produit que tu souhaites.
Si tu insères le produit dans le panier, alors c'est bien le produit et tous ses sous-produits que tu insères. Ca semble logique puisque tout n'est que pointeur.
Je pourrais aussi faire une relation one-to-many de Cart vers Subproducts. Et je pourrais donc toujours accéder au produit en question, puisqu'il est référencé dans le sous-produit (avec un ID unique).
Mais cela ne change rien au fait que dans mon panier j'aurais toujours le véritable objet "Sous-produit", au lieu d'en avoir une copie.
Tout ça parce que j'utilise des NSManagedObject.
Est-ce que la solution est de créer une copie du produit à votre avis ? Si oui, alors comment la créer, puisque si j'utilise mon ManagedObjectContext, cela va créer un véritable Produit qui va être stocké dans la BDD!
Et si j'instancie directement sans passer par mon ManagedObjectContext, cela ne me semble pas propre du tout, car je ne suis pas certain que c'est bien prévu pour !
Je divaguerai - il te faudrait déterminer ce qui est compréhensible :-*
De mon avis, ça vaudrait mieux de parler d'un produit qui possède une liste d' " attributs " tels que : description, couleur, mémoire, etc.
Donc, on pourrait avoir une classe Attribut qui comporte de Nom et Valeur - comme dans un dictionnaire.
Sans les Attributs, le Produit n'existe pas.
Tentatif de modèle...
Produit
- Descriptions disponibles
- Couleurs disponibles
- Tailles de mémoire disponibles
Un Panier qui peut contenir les Articles.
Article
- Description
- Couleur
- Taille de mémoire
C'est un peu comme une facture ou un devis.
N'hesites pas de me contredire ou de me poser plus de questions
Du coup je ne comprends vraiment pas pourquoi ça te gênerait de corriger ton modèle pour que Cart contienne une relationship One-to-Many vers Subproducts et pas vers Product.
Qu'est-ce qui te gêne sur le fait que ce soit le produit que tu mettes dedans et pas une copie ? En quoi c'est gênant ?
---
Et sinon le mieux à mon avis c'est d'une part pour la clarté / lisibilité de :
- Renommer ton entité Product en GenericProduct
- Renommer ton entité SubProduct et SpecificProduct
Et ensuite pour ton concept de panier de :
- créer une entité Article qui a une relation One-to-One vers un SpecificProduct et éventuellement d'autres attributs comme une quantité
- que ton entité Cart ait une relationship One-to-Many vers des entités Article et non plus des GenericProduct ou SpecifiProduct du coup
Pas de problème que ton panier contienne le véritable produit.
Pour moi, la "Couleur Or" n'est pas un "sous-produit", c'est un attribut. L'objet acheté est-un iPhone 5S, c'est une caractéristique essentielle. Le fait qu'il ait-une coque Or ou Noir est une caractéristique accidentelle. Le fait de changer la couleur de la coque (même avec un pinceau) ne fera pas de l'appareil un iPad.
A partir de là , tu as plusieurs solutions possibles, soit tu restes dans l'entité et tu définis toutes les propriétés (attributs) possibles, soit tu considères les accessoires comme des entités et tu effectues des liaisons one-to-many:
Entité Appareil : iPhone 5S [relationship: mémoire]
<<
> Entité Mémoire [attribut: taille en Go] [relationship: appareil]
Entité Appareil : iPad 3 [relationship: mémoire]
J'ai cru lire quelque part qu'il n'est pas recommandé de dériver des entités Core Data (mais ça marche, bien sûr). Tu peux fort bien faire du SpecificProduct d'AliGator une classe abstraite.
En fait, le problème que je perçois est dans la définition du modèle, pas dans le code. A partir du moment où le modèle est bien conçu, le reste relève de l'esthétique.
Les termes sont très génériques car ca pourrait aussi bien être ceci comme exemple :
Produit : BIllet de théâtre
Sous-produit : Balcon ; ou alors Première rangée, etc.
Le prix s'applique à un sous-produit et non à un produit. Je trouve mon modèle bien conçu pour l'utilisation que je vais en faire.
Mon problème est réellement le fait que j'ajoute les vrais produits dans mon Panier.
Car j'ai un attribut Quantité, qui est sur le sous-produit. Cet attribut, après avoir payé les produits, je dois les remettre à 0 pour tous les sous-produits en question.
Alors que si j'avais des copies des sous-produits ou du produit, je pourrais simplement faire un 'DELETE' de mon panier ...
Bref ça implique une gestion énorme pour pas grand chose ! Et je parle ici uniquement de cet exemple pour remettre à 0 la quantité, mais j'en aurais d'autres à citer dans mon application. En gros je gratte du code pour rien à mon avis.
Comme expliqué plus-haut dans mon message, le problème n'est pas le modèle mais le fait d'utiliser les vrais objets.
Est-ce que quelqu'un aurait une solution propre pour faire une copie de l'objet, sans le sauvegarder dans le ManagedObjectContext ?
D'abords merci pour tous vos avis.
Ta solution est juste un modèle différent, et cela se tient. Sauf que cela ne change pas mon problème.
Dans ton cart, j'aurais toujours un article, qui lui-même contient le véritable objet SpecificProduct, et du coup je manipule ce qu'il ne faut pas manipuler.
Je veux vraiment une copie de l'objet, pour une raison notamment la réinitialisation du panier après achat qui va plus vite comme je l'ai expliqué.
1. C'est plus logique de séparer le SpecificProduct (description d'un produit) et l'Article (article d'une commande, qui référence un SpecificProduct mais a aussi une quantité et peut-être une code promo et d'autres choses)
2. En utilisant Article tu ne modifierais du coup jamais tes SpecificProduct juste pour leur mettre une quantité que tu devrais penser à remettre à zéro, ce qui n'est pas très clean d'avoir cet attribut ayant des valeurs temporaires, alors que le produit lui-même n'a pas à changer vraiment
3. Tu peux créer une Delete Rule "Cascade" entre ton entité "Cart" et ton entité "Article" (mais une Delete Rule "Nullify" entre ton entité Article et SpecificProduct). Comme ça, quand tu détruis le panier, ça détruit automatiquement tous les articles qu'il y avait dedans (donc ça supprime les entitées Article de ta base tout seul) sans supprimer les SpecificProduct pour autant. Et comme ça tu n'as pas en plus à remettre manuellement tes compteurs de quantité à zéro pour vider ton panier, ça se fait tout seul.
4. Et là tu manipules ce qu'il faut manipuler. Tu ne manipuleras jamais le SpecificProduct qu'en lecture seule (pour afficher la description du produit dans ton panier, etc), mais tu ne le modifieras jamais (puisque ce n'est pas lui qui porte la quantité, mais ton entité "Article").
Donc même pas besoin de "copie de l'objet". C'est une mauvaise piste et une mauvaise notion que de partir vers ce concept de copie. D'ailleurs ça rejoint les principes de base des Bases de Données et des Modèles Objet : quand on a un objet dont on risque de faire référence plusieurs fois à plusieurs endroits différents ne jamais dupliquer les valeurs (faire des copies) mais faire une relationship.
Vraiment, comme on l'a déjà dit plus haut, je pense qu'avoir un modèle plus adapté résoudra tout seul plusieurs de tes problèmes. Là il s'agit juste d'avoir une entité "Articles" en plus de tes entités existantes, et que ton entité Cart ne pointe plus vers des Product mais vers des Articles. C'est tout. Et tout va du coup couler de source. Oublie ton histoire de copie et réfléchis en terme de MDD tu verras que c'est vraiment la solution qui s'impose.
Pas de tout d'accord avec toi, c'est la même logique que les produits iPhones. Un balcon n'est pas un sous-produit de Billet de théâtre. Revoie ton modèle comme suggéré par les autres
Ton idée de faire une copie d'un objet qui n'est pas dans le Context est une piste complètement mauvaise. Pour réinitialiser le panier après achat : il te suffit de créer un nouveau panier !! (tu peux aussi garder le panier et mettre à zéro ses relationships)
Le modèle que t'a proposé Aligator est plus adapté que ton modèle.
Le NSPersistentStore permet de juxtaposer plusieurs NSManagedObjectContext. Si tu fais ainsi tu t'en réserve un pour le panier et un autre pour ton magasin et tu peux chercher dans celui que tu veux.
J'ai utilisée cette technique pour différentier des objets Undoable et NonUndoable avec ce code que tu peux adapter à ton cas.
Par contre il faut penser à sauvegarder le deuxième NSObjectManager lorsque le premier est sauvegardé. Pour cela je mets en place une notification qui me permet de le faire automatiquement si besoin est.
Et qu'en plus un seul de ces MOC ne sera lié au PSC (donc impossible de garder le panier en mémoire si tu quittes l'appli et la relances plus tard)
Moi je vois l'utilisation de MOC différents exactement comme des branches en GIT. En général tu en as un principal (master) et le temps d'une opération (édition d'une entité, parsing de WebService et création de nouvelles entités, etc) tu crées un MOC fils du master (une branche) tu fais les modifs dessus et à la fin tu save (merge) le MOC fils (la branche) sur le MOC parent (le master). Ou alors tu détruis le MOC fils (Delete de branch) si tu changes d'avis et veux annuler les modifs.
Par contre 2 MOC qui vivent en permanence en parallèle pendant toute la durée de vie de l'appli c'est une synchro permanente de l'un dans l'autre et vice-versa pour que si tu crées ou supprimés des objets d'un côté ils existent aussi de l'autre... mais pas non plus une synchro si continue que ça car il ne faudrait pas que ton panier affecte ton catalogue de produits.
Du coup dans le cas précis qui nous intéresse, je pense qu'adopter un modèle comme celui que je te propose est non seulement plus clair et plus simple à mettre en place, mais aussi et surtout moins sujet à bugs et ne nécessite pas de mettre en place ce genre de mécanisme de synchro de 2 MOC, qui est plus compliquée à mettre en place (et qui peut se valoir quand c'est nécessaire mais qui est trop lourde pour le cas qui t'intéresse)
Les deux MOC (ou plus) sont liés au PSC et lus lors de l'ouverture de l'application et je ne vois pas la nécessité de synchroniser leurs contenus puisqu'ils sont indépendants.
Il y a un seul inconvénient : pas de lien possible entre les objets de différents MOC.
C'est bien expliqué ici.
En plus s'ils sont liés au même PSC ils auront donc le même contenu à l'ouverture de l'app (qui sera le contenu du sqlite).
Alors que dans notre cas précis ce n'est pas ce que l'on veut (contrairement à dans ton cas à toi où là oui c'est justifié car tu travailles avec le même contenu mais l'un avec un undoManager et l'autre sans, donc dans ton cas c'est en effet une bonne idée mais dans le cas du Cart qu'on a ici ça colle moins).
Dans notre cas ça serait éventuellement l'inverse même plutôt, un MOC lié à la base et contenant tout le stock et un MOC vide point de départ du panier d'achats, et donc non lié au PSC pour ne pas contenir tout le contenu de la base dès le lancement puisqu'à la base ton panier est vide.
Pour donner la version complète, et afin que ce soit clair pour tout le monde, l'application utilise une BDD externe (qui est sur un serveur et qu'on récupère avec des requêtes JSON). Le problème ne se situe pas à ce niveau.
Mon vrai problème était que j'essayais d'appliquer à la BDD interne, le même schéma de conception qu'à la BDD externe. Or, à l'extérieur on ne gère pas de panier, c'est uniquement dans l'appli, et je ne voulais pas la complexifier inutilement, mais il est évident que je n'ai pas le choix.
En voulant en faire moins, je me suis retrouvé à en faire plus
C'est vraiment la notion à retenir !
Je vais passer le topic en résolu, car l'approche d'Aligator est clairement la bonne.
Merci à tous pour vos échanges constructifs.
Non. À l'ouverture ils récupèrent chacun leur propre contenu !
Ou alors tu utilises 2 bases différentes ? Mais dans ce cas, comment tu fais des relationships entre tes objets d'une base (celle contenant ton stock) et les objets d'une autre base (celle contenant ton panier) ?