I hope that by "corrupt data" in the case of a many-to-many
relationship, you mean that if one isn't careful they may end up with
a row that links a foreign key from one table to a non-existent key in
another.
I mean no inverse relationships never have a join table, so trying to
pretend it's a many-to-many will just be wrong. *also* if you're not
careful maintaining the unmodeled inverses yourself, you can have the
problem you describe.
Can you elaborate a bit on this object graph corruption?
No inverse relationships cannot masquerade as implicit many to many
relationships. Plus, maintaining the unmodeled inverse yourself tends
to be more challenging than most people initially estimate.
Developers typically underestimate how much work it will be to do so
correctly and efficiently. Under some circumstances, no inverse
relationships are very handy, but that's the exception to the rule.
I was under the impression that I could just create a heap of
objects, string a
few of them together myself, and life would be great. However, it
seems that Core Data may be way way more particular about the
"strings" than I thought.
We distinctly prefer the relationships be fully modeled. Everybody's
life is easier and clearer that way. Fewer bugs, faster development.
More goodness in every bite.
Is Core Data really that particular if I go to add an object to a
set, and it can't set a relationship on said
object telling it which ONE set it belongs to?
If you don't model the inverse, we can't help you in many ways. The
model is incomplete. As for there being only one owning set with
partially modeled relationships, that's basically just a fact of
life. You're welcome to try to implement it yourself in SQLite or
another db technology. If you make it work, you'll have recreated a
fully modeled many-to-many relationship. If that's what you want,
then just do that in the modeling tool now.
Tools and development environments should encourage people to
gravitate towards the best solution. It's why programming languages
develop idioms. There are very few good reasons to use a no inverse
relationship. The compiler is informing you that most people doing
what you're doing regretted it.
but I'd really like to figure out how to implement things like Sets
and
MapTables (whose performance characteristics I can grasp) in Core
Data.
Sets can be represented as either to-many relationships, or through
fetch requests without a sort ordering. "get me all the objects of
that entity" is a set. Most collections in Core Data are naturally
sets. Fetch requests with a sort ordering are the principle form of
arrays in Core Data.
Map tables are keys (attributes) plus the above. They can be modeled
either by fetch requests with a predicate for the key, or as a first
class entity with a to-many relationship to the values.
The performance characteristics are typically I/O and memory bound,
and don't correlate well to in memory collection classes. -
executeFetchRequest:error: and -save: always perform I/O.
Relationships and faulting have some caching to back them. They can
be faster than fetching, but are also more constrained in structure
and features. Of course, you can added your own caching with a fetch
request to alter the performance characteristics further.
There's a whole section in the Core Data Programming Guide on
performance. Much of it is focused on amortizing and batching I/O.
- 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
