Re: Core Data fetch performance, design pattern sought
Re: Core Data fetch performance, design pattern sought
- Subject: Re: Core Data fetch performance, design pattern sought
- From: Quincey Morris <email@hidden>
- Date: Thu, 2 Sep 2010 16:01:06 -0700
On Sep 2, 2010, at 14:46, Sean McBride wrote:
> I have 2 CoreData entities, Foo and Bar. Both have 'name' string
> attributes. There are textfields allowing the user to rename any Foo
> and any Bar. Assume no 2 Foos can have the same name; likewise for
> Bars. There is a relationship between Foo and Bar. I want a Foo to be
> related to a Bar if and only if their names match. That is, when the
> user renames a Foo (or a Bar), I want to add/break a relationship
> between the Bar (or Foo) of the same name.
>
> Up to now I've done this by implementing Foo's setName: to 1) change
> self's name and 2) fetch Bars of the same name. Likewise for Bar. This
> works. But it's slow if a single user action changes many names at once
> because many redundant fetches are performed.
According to the above, what you really want is an implicit relationship between Foos and Bars, based on name identity. That's "relationship" in the design sense, not in the Core Data sense.
a. Have you asked the question whether you need an explicit (Core Data) relationship as well? What are the implications of traversing your object graph by name (i.e. by fetching according to name) instead of by explicit relationship?
b. Assuming you do need the explicit relationship, I'd suggest it's functioning as a "cache" for the implicit relationship. So, you could implement it that way. Override the Core Data relationship property accessors, and try using the "cached" primitive relationship first. If that fails, fetch the related object by name and "cache" the result in the primitive relationship. (Specifically, I mean: if the object has an existing related object, check the related object's name. If it doesn't match, or if there is no related object, then fetch the related object.)
If the related object is in memory, this access is slower but not incredibly slower than the built-in accessor (unless you have very stringent performance requirements). If the related object is not in memory, or it the relationship is stale, then the access is also going to cost you a fetch.
There's probably another viable intermediate option, too. When changing a name, you could defer refreshing explicit relationships until any explicit relationship is, er, explicitly accessed. At that point you could refresh all accumulated stale relationships. That would bunch up the update processing, but might reduce unnecessary fetching, compared to your original proposal.
It all kind of depends on your performance requirements. Possibly even, redundant fetches are cheaper than anything I'm suggesting, in your usage scenario.
_______________________________________________
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