On Aug 16, 2009, at 8:00 AM, Squ Aire wrote:
I have an Employee entity with the attribute userInfo, which is a
binary data type that stores some NSDictionary of key-value pairs.
Sounds reasonable.
With time, as the user uses the app, "garbage" will pile up (albeit
gradually) in these dictionaries that are associated with the
employees. And by "garbage", I mean key-value pairs that are not
needed any more.
... so you don't want the "userInfo" attribute to persist? In this
case, make sure you understand transient attributes and don't persist
the "userInfo" attribute.
I really don't want to clean the garbage "on the go/before
persisting" because I don't want to let the user wait unnecessarily.
The purpose of this garbage buildup is the benefit of more
responsive app, at the cost of little more temporary storage. I need
your advice on how to actually make it temporary.
*Temporary* storage == transient attribute. This should suffice for
most cases.
If, on the other hand, there's so much data that you need to clean
it up before the app quits, you really need to ask yourself this
question: Why aren't you cleaning it up immediately as soon as it's no
longer needed?
Continued below:
How would you clean up this garbage in such a way the user will not
notice it? I have thought of two ways. Which would work? Which are
impossible? Which is better? Do you recommend any others?
1.
When the app is idle, keep selecting random employees to clean up
key-value pairs within them ...[snip]... Will Apple's "Treading
Programming Guide" help me with it?
First, I realize you mistyped and left out the "h", but "Treading
Programming" sounds like one of those methodology books whose title
reflects the thing to avoid. ;-)
Second, sure, you could have a background cleanup thread, but the
net result of this approach is roughly the same as your second ...
2.
...[snip]... would I be able to create threads for this task, create
MOCs for each of them, do the cleaning on those threads, and hand
those threads to GCD?
I believe (hope) this is public knowledge, but GCD is essentially
"easier concurrency" without worrying about thread management.
"Six of one, half-dozen of the the other."
It sounds fancy and cool, but is this even a realistic solution?
Sure it is, but your suspicions are correct:
The problem I can think of is that when actually saving the "main
MOC", the main MOC will still contain the garbage and wouldn't be
able to figure out whether to persist the garbage or not.
I really think you need to (re)read the Core Data Programming
Guide. You will of course need to manage the merging of the different
contexts yourself and that will require you to think this through long
and hard.
Of course if your "userInfo" attribute does not require
persistence, none of this should even be necessary.
Finally, note that I cannot use willTurnIntoFault, and clean up the
garbage there, because it is very inefficient in my case to do the
clean up for the managed objects one by one.
Okay, this is what it comes down to: You need to tell us the exact
nature of this attribute. Does it need to persist or not?
Also, your assertion that -willTurnIntoFault is highly suspect.
Where's your performance testing data to back it up? How have you
implemented it? If the entity instance was faulted and the "userInfo"
data is transient, isn't this the perfect time to let the "userInfo"
data go? As it's no longer needed on an instance-by-instance basis?
And again, the user would have to wait while saving, which is a bad
solution.
This is where the confusion exists ... you say
"temporary" (transient), then you say "save" (persistent). Which is it?
--
I.S.
_______________________________________________
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
