@mark: I just wish more people were familiar with the way active record (in ruby on rails) handles the same kinds of issues than core data
ActiveRecord is well-designed, but it's not setting out to address the same things as Core Data. For example, a Mac app may need to account for a case where a user launches an application and wants to scroll 8,000 items in a table, each containing multiple megabytes of data.
It's easy to use, it has a clutter free clean API, it uses only subclasses, no parallel-universe entities
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.
It's also particularly important for multi-document applications or a single-document application which loads data from multiple stores and projects them as a single store.
by Scott Stevenson — Nov 11
ActiveRecord is well-designed, but it's not setting out to address the same things as Core Data. For example, a Mac app may need to account for a case where a user launches an application and wants to scroll 8,000 items in a table, each containing multiple megabytes of data.
It's easy to use, it has a clutter free clean API, it uses only subclasses, no parallel-universe entities
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.
It's also particularly important for multi-document applications or a single-document application which loads data from multiple stores and projects them as a single store.