Let me explain how I solved the same problem: I have an application that stores large data files via Core Data. Multiple users access the same data at different times, and each user has a preferred way of visualizing the data. E.g. starting point, filter sets, color coding, etc. all differ for every user for every document. The user's want their view configurations preserved even if the last person who modified the data used a different view configuration. My solution: Most of my Core Data entities have a Data blob attribute which is actually and archived dictionary of "extra data." Each user's per-document view configuration is stored under keys within each blob. The Data blobs start out nil which just defaults to something reasonable in each view. Question 1: Why not store the view attributes in separate Core Data attributes or in relationships ? Answer 1a: The application allows users to strip all view configuration information out before delivering to a customer. That makes the files smaller and removes information that won't benefit the customer anyway. It's easy to strip the information by just walking through all entities and setting the "extra data" attribute to nil. Answer 1b: Most user's never set most "extra data" attributes, so why reserve storage for pointless default values. Plus, I can invent new view attributes at any time by just using new dictionary keys without changing the Core Data model. Question 2: Why store the "extra" data in Core Data at all instead of a separate file in a "bundle"?: Answer 2: I tried it both ways, and there didn't seem to be any reason to create an extra file per document just for this. Question 3: Doesn't this violate the MVC pattern? Answer 3: The Model is "any data the user cares about", so if the user cares about the position and color of elements, that information is part of the Model. The only issue is that different users want different information about the same data. Sometimes a single user wants multiple conflicting sets of information about the same data. I actually show the user all of the "named view configurations" that are available in a particular document and let the user pick which one to view at that moment. The user can have multiple views of the same data open at once. Question 4: Why not use Core Data's context merging features and store extra data in a separate context? Answer 4: I didn't know how, and it didn't seem necessary to learn at the time. _______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
