A Few Basic Core Data Questions
A Few Basic Core Data Questions
- Subject: A Few Basic Core Data Questions
- From: "Justin Carlson" <email@hidden>
- Date: Sat, 04 Feb 2006 17:27:03 -0600
Here is a discussion I posted to the wrong list and was referred to post it
in the Cocoa area:
Thanks in advance for any advice.
Date: Fri, 03 Feb 2006 15:25:07 -0600
From: "Justin Carlson" <email@hidden>
Subject: A Few Basic Core Data Questions
To: email@hidden
Message-ID: <email@hidden>
Content-Type: text/plain; format=flowed
Tonight and all through the morning I held my Core Data crash course
consisting of reading hundreds of pages of fora, documentation and example
code. Yes, I was THAT intrigued by it's immediate prospects, a few questions
I have not been able to answer other than "Should I go to sleep now?".
1 The passage from Core Data to existing data and Frameworks beyond it's
close relatives/subclasses seems obscure. I have read on and on and the
example code does not illustrate this well. Let's say I want to modify
properties, attributes, of existing files-say communicating with
NSFileManager... NSPersistentDocument doesn't seem to be the answer here...
2 Reading the data seems doable but just manipulating existing data and
writing it back to the file in the traditional sense is a bit of a mystery
here. Of course, all the while using the data modeling and spotlght/metadata
technologies.
3 If this is still valid, What good workarounds, caveats, etc, have you
encountered using Core Data beyond these limitations.
Thanks for any advice, I'm probably just thinking sideways right now. If
there is a good sample code example posted it should be all I need, to see
how Core Data integrates with other frameworks.
Justin
From: Markus Hitter <email@hidden>
Using Core Data you shouldn't have to fiddle with files at all. Create
table entries, manipulate them, delete them. All the storage is done
opaque without need for your interaction.
Other than that, Core Data is discussed a lot more on the Cocoa
Develompent list.
Markus
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/
Markus,
Thanks for the reply. That's what I was uncertain about. Having the files
and databases update while reflecting the changes is what I *want* to use
Core Data and Modeling for. The reason being, is that the attributes would
need to update files themselves, to an existing standard and setting up an
editor using data models would simplify the process significantly. I would
want files updated because the modified attributes should be relayed to
other applications to read and benefit from.
A simple example would be getting properties of songs in your iTunes
Library, manipulating ID3 tags (like the Info panel in iTunes), and sending
them back, updated-this is also useful for other media players to read the
ID3. Let's forget about the fact that iTunes would be confused and so on,
this is just a hypothetical illustration. Certainly data modeling and
creating such an editor could be done much more efficiently than writing an
app from scratch, not to mention how models could be reused and the process
and writing, modeling, deploying of such an application would be able to
happen that much easier. It seems that Core Data is not designed for that,
instead it uses it's own databases which either inherit from files or user
created databases. Bridging Core Data functionalities so it is a two-way
street is what is elusive to me, it seems like Core Data integrates with a
select few classes.
If that is how it works then it's use is questionable for such an
application. I just wanted to get a clear answer before spending much time
integrating it and finding out after much time was invested.
Does Core Data integrate as you have described using the iTunes/ID3 example?
Thanks,
Justin
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden