Re: ADC Core Data article
Re: ADC Core Data article
- Subject: Re: ADC Core Data article
- From: Philip Mötteli <email@hidden>
- Date: Wed, 06 Apr 2005 14:47:07 +0200
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.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden