Before anything else, let me say thank you for a clear, concise, and
very helpful set of answers to my questions; I was expecting rather
more of a struggle for understanding :).
my pleasure.
On Sep 10, 2009, at 5:04 PM, Ben Trumbull wrote:
The inverse
relationship from Planet to Employee, "all employees from this
planet"
is technically feasible, even easy, to model, but it's almost
certainly a waste of time and effort. But the Core Data
documentation
offers a long list of very dire warnings about one-way relationships
between entities.
Yes, and for most situations those warnings are there for very good
reasons. But if there were no reasons for such relationships, then
it wouldn't be a warning, it simply wouldn't exist.
The manual isn't at all clear about this, but if I understand
correctly, you're basically saying, "Though it is almost always
technically possible to model an inverse to any relationship, there
are sometimes circumstances in which it is correct not to do so." Is
that accurate, and if so, should I file a documentation bug requesting
clarification on that and the circumstances in which it's true?
Sure. It's a challenge to document some of this material in a way
that steers most developers down the typically optimal path while
still keeping advanced options open. We have many developers with
little or no database experience, and we want to encourage them to use
inverses until they have a compelling reason not to. The
documentation was more open about no inverse relationships in 10.4,
and we learned the hard way that was less than ideal. The modeling
tool now issues warnings for this due to the frequency and severity of
bugs from developers incorrectly and over eagerly using no inverse
relationships.
But oops, Core Data can't
model cross-store relationships, so you use a fetched property,
which
is one-way.
You could use a fetched property, or handle this in code by storing
a URI for the destination object in a different store, and fetching
the matching objectID either lazily in in -awakeFromFetch. We've
generally recommended using a custom accessor method for this
instead of fetched properties.
Is there any particular reason for that recommendation? The
documentation explicitly recommends fetched properties for cross-store
relationships (one instance of several is in the Core Data Programming
Guide, "Relationships and Fetched Properties" chapter, "Fetched
Properties" section, first paragraph, where it says " In general,
fetched properties are best suited to modeling cross-store
relationships...")
First, custom accessor methods and -awakeFromFetch offer a vast amount
of flexibility, and can be easier to tune for performance. Fetched
properties are a fine alternative. But I like to also reinforce the
understanding that not all your custom behavior needs to be
encapsulated in your Core Data schema. You have full Objective-C
objects and very powerful runtime support. Use it liberally.
(Let me take this opportunity to say that for all the warnings that
Core Data is not and never has been a database, almost every
concept I
see in it makes me think "O/R mapper for SQLite".)
Core Data is an O/R mapping framework, among other things. But O/R
frameworks are not SQL databases. Modeling your data in any O/R
framework as if you were writing SQL directly is inefficient and
mistaken.
Saying that Core Data is a database is like saying your compiler is
an assembler. Well, the compiler suite uses an assembler, sure, and
they both output object code in the end, but that does not mean the
best way to use your compiler is to write in assembly.
Nonetheless, Core Data does manage the data stored on disk as well as
the representation of that data in memory; I don't see a tremendous
difference between that and what SQLite does, other than Core Data
providing a much effective organization of and means of access to that
data.
Core Data implements a lot of functionality on top of SQLite. From an
API perspective, that it uses SQLite at all is an implementation detail.
In any event, O/R systems present an OO view of your data, and have
their own idioms closer to OOP. They are providing an abstraction
layer and perform transformations on both your queries and result
sets. Relational databases can support that, but in every O/R system,
the ideal way of using the system is somewhat different from how one
would write SQL directly against the database.
- Ben
_______________________________________________
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
