@mark: We have had initWithCoder: etc. a long time to serialize objects. Why NSManagedObject couldn't just use something like that and leave storage details for the persistent store?
I'm not quite sure what you mean. NSManagedObject doesn't do any sort of persistence itself, and it does leave all of that to the persistent store. If NSManagedObject serialized all of its data prior to handing it off to SQLite, I think it would negate the benefits of SQL or multiple store types in general. Maybe I misunderstood your point?
I don't see any benefit in keeping NSManagedObject separate from it's corresponding NSEntityDescription
NSManagedObject is a runtime class that holds data, and NSEntityDescription is a class that tells you about the schema/model. They have different responsibilities, so I'm not sure it would help to combine them.
Maybe core data could be modified to be more activerecord like by always generating custom subclasses of NSManagedObject which would automatically be associated with corresponding NSEntityDescription?
That's effectively how it works, though without actually making a public subclass. In Leopard, NSManagedObject instances fill in methods for all of their modeled properties. So if you have a property called "fullName", Core Data will automatically add the "fullName" getter and "setFullName" setter at runtime.
I hope that helps. If I didn't cover something, let me know.
by Scott Stevenson — May 24
I'm not quite sure what you mean. NSManagedObject doesn't do any sort of persistence itself, and it does leave all of that to the persistent store. If NSManagedObject serialized all of its data prior to handing it off to SQLite, I think it would negate the benefits of SQL or multiple store types in general. Maybe I misunderstood your point?
I don't see any benefit in keeping NSManagedObject separate from it's corresponding NSEntityDescription
NSManagedObject is a runtime class that holds data, and NSEntityDescription is a class that tells you about the schema/model. They have different responsibilities, so I'm not sure it would help to combine them.
Maybe core data could be modified to be more activerecord like by always generating custom subclasses of NSManagedObject which would automatically be associated with corresponding NSEntityDescription?
That's effectively how it works, though without actually making a public subclass. In Leopard, NSManagedObject instances fill in methods for all of their modeled properties. So if you have a property called "fullName", Core Data will automatically add the "fullName" getter and "setFullName" setter at runtime.
I hope that helps. If I didn't cover something, let me know.