Part of the reason entities exist is that a desktop application doesn't always want to use SQL. In the case of using XML or a binary (or even in-memory) store, you can't depend on table and column definitions. In Leopard, you can implement your own store types using NSAtomicStore.
Could you elaborate on this, I don't quite understand how this has anything to do with the store type, be it sql or plain text. 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?
That being said, I don't see any benefit in keeping NSManagedObject separate from it's corresponding NSEntityDescription - other than having not to force creating custom subclasses of NSManagedObject. Which, it seems to me, is not a benefit at all, on the contrary.
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?
by mark — May 23
Could you elaborate on this, I don't quite understand how this has anything to do with the store type, be it sql or plain text. 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?
That being said, I don't see any benefit in keeping NSManagedObject separate from it's corresponding NSEntityDescription - other than having not to force creating custom subclasses of NSManagedObject. Which, it seems to me, is not a benefit at all, on the contrary.
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?
Any thoughts appreciated.