Re: ADC Core Data article

FROM : Philip Mötteli
DATE : Wed Apr 06 14:47:07 2005

Am 06.04.2005 um 01:14 schrieb Scott Stevenson:
> On Apr 5, 2005, at 2:49 PM, Philip Mötteli wrote:

>>> Each entity definition in a managed object model requires the name
>>> of the entity and the name of the class used at runtime to represent
>>> that entity. By default, the class used is NSManagedObject, but the
>>> class may be either NSManagedObject or a subclass thereof.

>>
>> I read that phrase 5 times. Is that really true? Only subclasses of
>> NSManagedObject get managed persistency from Core Data?

>
> Trying to implement transparent persistence without a persistent
> subclass is.... challenging.


We had it with EOF, including un-/redo.
I wouldn't say, it's challenging. It's a lot of work, but we could even
go much further. We wouldn't even need a model.
Well there's one problem: All the classes, which implement all iVars
just as (e. g. void*) or are based on Core Foundation are a real pain.
Those would have to be treated specially. But at least me, I don't do
such things. And I don't know any third party libraries either, except
Apple's.


> The reason that NSManagedObject is distinct from NSObject, is that
> there are many situations where persistence isn't needed or wanted. 
> You should derive your model objects from NSManagedObject, not every
> object in your apps.


I thought you define that in your model? All the classes, that are in
the model, are entities in the DB.


> Managed objects (among others) actually *store* the attributes and
> relationships ("The NSManagedObject ... acts as a dictionary"): that
> would be one of the main features which needs an extra class.


We had that with EOGenericRecord. But you don't need to subclass this
class in order to get persistency in EOF.


> Just cosnider this: a managed object would have to contain some kind
> of a dictionary to contain the data themselves. Judging by the EOF
> example, there probably would be also a link to its entity descriptor
> (whatever class it is defined by--might be a dictionary, too, if
> simplified enough) to define the data structure. Another link would be
> needed to the object's EOEditingContext -- sorry,
> NSManagedObjectContext :)) -- and so forth.
>
> It would be too much to suppose all these things would be part of
> NSObject, would it not?


How did they do it in EOF? They did manage this information externally
to the object itself.
Even isa swizzling would be another possibility, though I would prefer
not to do that.


> On the other hand, if you don't need all these services and just aim
> for persistence, CoreData aren't what you need: just use an
> NSArchiver, and you get the support for any NSObject :))


I do agree, especially, that I have implemented all the necessary to
save any object transparently that way. But sometimes, when you have
millions or billions of objects, you would prefer letting that be
handled by a DB.


Please correct me, if I'm wrong, but I don't really see, what Core Data
has more to offer than EOF? I see though, that it seems to be a cleaner
and compacter implementation of a part of EOF, by leveraging some new
technologies.

I mean, Apple exploits more and more the rich runtime information, that
ObjC provides. If the implementor of a class doesn't use all the way
(void*) as iVars, everything is there. You just parse that information
and you have all the information, that is needed, in order to save all
the objects to a database (including creating tables and
relationships). So you do not even need a model. For aspect oriented
problems, like observing the mutation of objects (un-/redo) you can use
isa swizzling within an editing context.
In my eyes, we shouldn't have to change the design of our software, in
order to fit it into a specific persistence implementation. If I need
persistency, I should just have to link with an additional library of
choice and then being able to send to any object -saveToFileWithName:
or -saveToDatabase or whatever. Just one supplementary line of code.
Then the whole referenced object graph should be saved (of course on
could implement some mechanisms to exclude certain objects). And that's
all possible. As I already said, I save a whole object graph of any
type of objects to a file without implementing any NSCoding protocol
(actually only one, that works for all objects, except the Procedural
mixin' like Core Foundation and iVars, that are not sufficiently
defined, like (void*), etc.