All object ivars (except the array for the next lower-level),
including those of Shapes,
reside in dictionaries. These have certain required properties plus many
optional properties, some not currently defined and some possibly not even
know to the containing object.
Assuming a large fraction of the properties are required, then the
extras can be modeled either in key/value tables or via a
Transformable property that just encodes a dictionary itself.
In general, it's better to model optional properties unless they are
so infrequent that they're just adornments. If they are that rare,
then the Transformable property trick works well.
Well designed systems are rarely so amorphous. In typical usage,
even most XML files and dictionaries usually have a preponderance of
mostly frequently used tags/keys.
Core Data is not intended for the very rare cases where a system
needs to have an infinitely malleable schema. Depending on the
latency requirements of the schema mutations, it might suit anyway
since NSManagedObjectModels can be constructed or altered at runtime.
Transient properties can be added with a hit of reloading the stack.
Persistent properties can be added if you can accept the performance
hit of migrating the old data file to the new schema.
Probably just my not understanding the CoreData.pdf (p.49) docs:
"If you have two subclasses of NSManagedObject where the parent class
implements a dynamic property
and its subclass (the grandchild of NSManagedObject) overrides the methods
for the property, those
overrides cannot call super. "
This is in reference to @dynamic properties. It has nothing to do
with traditional methods. @dynamic properties are sets of accessor
methods that the framework will provide at runtime if you do not
implement a custom implementation in source. If you do implement the
accessor in source, you can't call super because it never existed.
For traditional methods, the Core Data Reference Guide documents
which methods on core classes we expect to not be overridden. This
is because the framework has assumptions about how those methods
ought to behave, for various reasons including performance, @property
support, etc. The list looks long, but really all it says is "Core
Data expects NSManagedObject to behave the way we shipped it, and
NSObject to behave the way Cocoa shipped it"
On common example is people trying to override -isEqual: In doing
so, they break all the hash tables Core Data uses internally.
Usually what they really wanted to do, but didn't realize, was [[mo
objectID] isEqual:[otherMo objectID]]
--
-Ben
_______________________________________________
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]
