This may not be strictly related to your problem, but maybe it helps:
Transactions
Atributes: Amount:Double, Date:Date, Memo:String, Payee:String
Relationships: TransactionType
If these are the attributes of the entity you created in Xcode's
editor and you can set the class of this entity to a custom subclass
of NSManagedObject, then you can do something that is extremely
helpful: you can get the compiler to give you warnings about passing
wrong types for attributes and (to-one) relationships. Instead of
using -setValue:ForKey:, you can then use the dot syntax for all of
the properties and relationships.
Just create an NSManagedObject subclass that has no ivars, but a
property for every attribute and relationship (I never did it for to-
many relationships, but those *should* simply be properties of type
NSSet). In the implementation, just add an @dynamic myProp; for every
property. Then, set this custom class as the class of the Entity. Now,
instead of
[transaction setValue:tr.transactionAmount forKey:@"Amount"]; // the
value is of type id -> no type checking possible
you do
transaction.amount = tr.transactionAmount; // compiler knows that
"amount" is of type NSNumber and can emit warnings
(Keep the coding guidelines in mind: attributes should begin with a
lower letter)
Of course, the KVC stuff still works. And because you have your own
subclass, you can easily add properties and methods to get things like
compound values, like when you have an Person entity with the
attributes firstName and lastName, you can implement a -fullName
readonly property that returns [NSString stringWithFormat:@"%@ %@",
self.firstName, self.lastName];
Very handy.
another thing I would like to understand, do relationships work like
constraints in SQL ?
in the sense that if there is no transactionType defined in the
TransactionTypes Entity,
I would not be able to insert a value in the transactionType field
of the transactions entity?
You mean whether you can can set values for attributes that are not
defined in the entity? That's not possible, you'll get an
NSUnknownKeyException and by default, your applications crashes.
By the way, the approach with the defined properties described above
prevents this, because the compiler would throw a warning that you
sent a message without a matching method signature.
If you really need it, you could even do some trick and implement -
setValue:forUndefinedKey: in your NSManagedObject subclass to prevent
the exception from being thrown. There are classes out there (one
written by Mike Abdullah, if I'm not mistaken) that do just that: they
take an unknown key and store it along with its value in a
NSMutableDictionary ivar and every time you try to set/get a value for
an unknown key (unknown to the entity, at least), instead of throwing
an exception and crashing, the class happily lets you store/retrieve
the value. This way, you don't have to change the model if you want to
add a property, which can be useful if you want to add some tiny thing
in a future version of your application (changing the model breaks
compatibility with old models, unless you implement a mapping model).
I don't recommend relying on this heavily, though.
Marco
_______________________________________________
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 [EMAIL PROTECTED]
