Re: Looking for suggestions/help on a multi-file data model
Re: Looking for suggestions/help on a multi-file data model
- Subject: Re: Looking for suggestions/help on a multi-file data model
- From: Quincey Morris <email@hidden>
- Date: Sat, 12 Feb 2011 01:34:12 -0800
On Feb 11, 2011, at 18:08, Andy Akins wrote:
> Imagine a "purchasing" application. First, you have to open a "catalog" - a file that lists the items that are available. There might be multiple files, representing multiple stores or sets of items, but you have to pick just one.
>
> Then, you have your "order" - you select items from the opened "catalog", and have a new document that contains not only the items you are going to order, but also other information (address, name, etc).
>
> The catalogs are separate files, and there would be either a separate app or a part of this app to edit a catalog: to add, remove, change items in it.
>
> But orders are also separate files, that can be saved, edited, printed, etc.
>
> I've used Core Data and the Document architecture for more simple data models, but I'm not sure if I can shoehorn this into them. I've looked at several tutorials, guides, and even read some books - but they all seem to be the One Document = One File approach. And what I want to do really doesn't fit that.
>
> Note: The above is just a conceptual example - I'm not really writing a purchasing/catalog system. It was just what I thought of to describe my problem :) The actual product I'm working on is a bit more niche oriented, but the use case of the data involved follows the same concept: the "prime" document (order) is built/constructed using data from a defining document/template (catalog).
>
> Can anyone point me in a direction to do some more research and/or offer some insight that might help me decide if I can use Core Data and/or Document Architecture, of if I have to go old school and roll my own? Heck, perhaps I can use CD/DA for the primary document, and have the template/definition document be something else.
Only you can decide. :)
There's really nothing in your description that seems to be a natural fit with NSDocument. I can't imagine users wanting to create and save explicit document files for "orders" -- though in your application document files make more sense than in your imaginary scenario.
It's completely undecidable from this whether the "catalog" information really should be multiple files, or multiple Core Data stores, or a single Core Data store. Even if you have multiple files, you might still choose to have an umbrella Core Data store that aggregates the contents of the individual files, using links or pointers to the actual data in the individual files.
There's nothing inherently restricting NSDocument to a single file. In fact, the NSFileWrapper class exists to ease the use of file packages (i.e. folders) as the underlying storage of documents. However, the safety of the NSDocument saving architecture depends on copying all of the files on every save. Trying to get around that pretty much breaks the NSDocument metaphor for users, and you'd be better off spending your time doing something other than NSDocument.
Your design is also going to depend on what's a server and what's a client (i.e. what's shared between users and what's specific to a single user).
So you still at the stage where you need to think about design not implementation -- don't make the mistake of designing for a pre-chosen implementation strategy. First, start by designing your user workflow, which will tell you where you need your information, and when, and how it's going to get edited. Second, examine the workflow to see if the NSDocument metaphor (new, open, save, save as, revert, dirty, undo) applies. If not, don't proceed with NSDocument.
Only after all that can you decide whether you need a real database approach, or a Core Data database-ish object graph, or something else.
That's about as specific as I think is possible, given your description. Some other advice from the trenches:
1. Don't fight the NSDocument metaphor. You'll spend the rest of your life debugging your code (well, until the next major OS revision, at which time your code will break all over again), and your users will never be happy.
2. Try to avoid doing anything funky with Core Data. Remember that it's pretty much a black box for 3rd party developers, and if you try to bend it to your will, you'll end up in a great deal of pain.
3. Be even more careful trying to adapt NSPersistentDocument. Even in its simplest use, it's a terribly fragile marriage of two incompatible metaphors (NSDocument and Core Data). Breathe on it and it will break. :)
Maybe that sounds overly negative. The positive version is: always work *with* the frameworks, not against them.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden