Re: Cleaning "garbage" in Core Data
Re: Cleaning "garbage" in Core Data
- Subject: Re: Cleaning "garbage" in Core Data
- From: Caleb Strockbine <email@hidden>
- Date: Sun, 16 Aug 2009 16:35:36 -0400
On Aug 16, 2009, at 3:02 PM, Graham Cox <email@hidden> wrote:
On 17/08/2009, at 1:47 AM, Squ Aire wrote:
Key-value pairs in the userInfo dictionaries are "marked as garbage"
as the app is running and depending on various factors.
Don't "mark as garbage" - delete them. Problem solved. If you need
them to stick around in the garbage state, they're not garbage!
My guess (and what more can we do, really?) is that Squ is generating
these keys automatically, maybe based on the date or some user
preferences or something, and storing values for those keys for each
user. At some point later on, due to passage of time, changing
conditions, whatever, some of the keys become invalid. I think that
even though he(?) says the key/value pairs are marked as garbage, he
probably means that the keys are removed from some list of valid keys.
Squ, if this is all correct, some things to consider:
- Rather than removing invalid key/value pairs from the userInfo
dictionary, it may be faster to copy the valid keys to a new
dictionary and dump the old one.
- Have you profiled your code? There are a few things in your proposed
operation which sound like they might take up a lot of time, but it's
impossible to know for sure without profiling. Implement the simplest
solution you can think of and then do some measuring.
- Depending on the results of the profiling, you might want to rethink
the data structure you're using, or how you're using that structure.
For example, if you keep a dictionary for each of the attributes that
are currently represented by your userInfo keys, and use Employee name
or ID or whatever as the keys into each of those dictionaries, then
removing all the data for a garbage key is just a matter of deleting
the corresponding dictionary. (Of course, you still have to solve the
same problem you have now, but you only have to do it when an Employee
is removed from the system.) The point is: let your performance data
and operational requirements be your guide.
There are a lot of smart people on this list, and they'd be happy to
help them if you give them something concrete to work with. Sometimes
there are reasons that you can't reveal exactly what you're doing, but
if that's the case you ought to work up some sample code that
illustrates the problem you're having.
-Caleb
_______________________________________________
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