Re: How to keep creation/modification date of a (Core Data) object?
Re: How to keep creation/modification date of a (Core Data) object?
- Subject: Re: How to keep creation/modification date of a (Core Data) object?
- From: Tony Becker <email@hidden>
- Date: Wed, 11 Jul 2007 14:23:39 -0400
Not sure what's up - we do this here all the time, in many places,
with core data.
Typical scenario is unit + type:
Core Data attributes:
unit (NSNumber *) some value
type (NSNumber *) enum of hours, days, weeks, etc.
Transient attribute (NSString *) is value + type
Then we trigger change notifications from the original keys to the
new transient attribute.
Any changes to the original values trigger a "get" of the transient,
with the following caveats:
in + (void) initialize, we exposeBinding of the transient, and, of
course, we have a binding to the transient in a .nib somewhere.
we do (must have) have a transient "setter" in our code, even if we
don't use it - otherwise we'll get an error in the .nib (i.e.:
requires KVO)
the transient "getter" still has to make up the string of unit +
value (stringWithFormat), of course. There is no "magic" that puts
them together.
In the absence of any accessor code, the default setValue/
valueForKey functionality in core data (KVC) works - but, if you
overwrite your core data attributes with accessor methods you MUST
supply (correctly) will/did change value for key code.
In addition, in some cases, we do have transient "setter" code that
separates the string into it's core data components, and sets their
primitive values, but thats a little more complex - but it works too.
Where I've debugged this, when it's not working:
missing the exposeBinding to a transient attribute (+initialize)
missing the triggerChange (+initialize)
missing KVO/KVC methods - can quietly fail, with no warnings.
Somebody is checking for selector first, and not calling because it's
missing.
spelling, spelling, spelling (Camel Case)
On Jul 11, 2007, at 1:49 PM, Arthur C. wrote:
I believe you need both set/getter methods to be KVC compliant,
and thus, for the dependent key trigger to work.
Watch for typo's and make sure the originalKey is also KVO
compliant (will/did change if Core Data)
+ (void) initialize {
[self setKeys:[NSArray arrayWithObject:@"originalKey"]
triggerChangeNotificationsForDependentKey:@"newKey"];
...
}
-(void)setNewKey:(id)val {
...
}
-(id)newKey {
...
}
Okay, but I have done that. Instance variable with setter and
getter, and no typos. Does it matter that I'm adding a variable/key
to a Core Data object? I don't want to include the extra variable
(modificationDateChanged or something) in the data model, as I
don't use it anywhere except for the triggerChangeNotification.
So why does the triggerChangeNotification have no effect? It just
doesn't work.
Thanks again,
Arthur C.
On Jul 9, 2007, at 1:23 PM, Arthur C. wrote:
On 08/07/07, Arthur C. <email@hidden> wrote:
This must be a simple use of setKeys:
triggerChangeNofiticationsForDependentKey, but I can't find
the right method
for the key 'modificationDate'...
Creation date is easy, just an awakeFromInsert will do.
But the modification date (obviously) has to change whenever
any of the keys
in the object changes. Moreover, it has to keep its value when
we are just
asking for the modification date (getter method), and on program
shutdown/restart.
_________________________________________________________________
Talk with your online friends with Messenger http://
www.join.msn.com/messenger/overview
Tony Becker
Cell: 727 460 1891
Never be afraid to try something new.
Remember that the ark was built by amatures and the Titanic was built
by professionals.
_______________________________________________
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