[Biococoa-dev] More on CoreData

[Charles PARNOT]

Thanks for the pointer! The CoreData concepts have started to sink in my brain... I am not sure I grab all of it yet, but I hope these discussions will help.

It seems we have two related issues at this point if we want to support CoreData:
(1) The existing code does not fully support it
(2) How do we make the code both 10.2 and 10.4 compatible

Regarding point (1), you mention NSArray as a potential issue. Let's try to make a more exhaustive list: NSDictionary, NSSet, ..??.. Probably others. There is one point that is also unclear to me. NSArray seems to be covered by the one-to-many relationship between entities. Can that be translated into an NSArray concept? A related question is performance, when we are dealing with large NSArray of NSSymbol.

Related to that, I can see how NSManagedObject subclasses can add behavior, but how does one add costum properties? Just adding ivars? Is it then just a matter of having KVC support? How is coding supported, just NSCoding? Or should all object ivars be subclasses of NSManagedObject? How does the NSManagedObject class know that properties have been added? Can we create a NSManagedArray class to wrap NSArray?


Regarding point (2), the mock NSManagedObject is a very good way of doing it. An alternative is a:
#define NSManagedObject NSObject for the 10.2/10.3 build. Of course, on top of that, you still want the CoreData implementation to be transparent to earlier systems. It is also fairly easy to add #ifdef around code that we don't want to compile in the 10.2/10.3 build. If we use of precompiler tags , then we get two different bundles, one for each version of the system.

Either way, in general, I think we should have full CoreData support and intermediary solutions that give up some of its functionality are not worth the trouble.


Finally, I think Koen raised a good point: it is still unclear to me how the user would want to use CoreData with the BioCocoa framework? It is the following: we providing NSManagedObject subclasses to the user, so the user can then use them transparently to implement its own CoreData solution in the application?


thanks for your feedback on all these questions, John!

charles

At 1:27 PM -0400 4/6/05, John Timmer wrote:
>In case anyone missed it, Apple finally put the overview article on CoreData
>up:
>http://developer.apple.com/macosx/tiger/coredata.html
>
>This finally allows me the liberty of making a few more comments on the
>problems we'll have supporting both this and earlier OS versions at the same
>time.
>
>The first is that all the objects that go into a CoreData store have to be
>subclasses of NSManagedObject.  This class isn't going to exist in any
>previous versions of the OS.
>
>The second is that many of the classes we rely on (ie - NSArrays) aren't
>native CoreData objects.  This means that, in order to stick an array into
>an NSManagedObject subclass in a saveable manner, we'd have to first convert
>it to data via NSCoding, or use its string representation.
>
>
>There's three ways I can imagine handling things:
>
>Create a "dummy" NSManagedObject subclass that's used to prevent compiler
>errors when built on < 10.4.  This seems like an awkward solution, but would
>allow us to start building CoreData compatibility into the basic classes,
>like Symbols and Sequences.  Since the class won't actually be NSManaged
>object, we can override some methods in our subclasses without worrying that
>they'll ever be called on earlier OS versions.
>
>Create a separate framework that allows conversion between our standard
>classes and CoreData compatible ones.  This would at least allow a
>collection of BioCocoa objects to be shuffled into and out of a CoreData
>persistent store, but wouldn't allow the use of some of the more advanced
>CoreData features, like relationships, etc. in our classes.
>
>Give up and make BioCocoa 10.4 only, or at least provide a 10.4 only fork.
>That's clearly the best from the feature perspective, but will clearly limit
>our audience.
>
>
>There may be other options, and once the NDA comes off, I'm sure the
>Cocoa-dev mailing list will be full of people looking for (and hopefully
>creating) solutions to similar problems.
>
>Anyway, I thought you guys would be interested (I could tell by Alex's email
>to Apple that he is ;), and it's always better to start major design
>discussions sooner rather than later.
>
>John

-- 
Help science go fast forward:
http://cmgm.stanford.edu/~cparnot/xgrid-stanford/

Charles Parnot
charles.parnot at stanford.edu

Room  B157 in Beckman Center
279, Campus Drive
Stanford University
Stanford, CA 94305 (USA)

Tel +1 650 725 7754
Fax +1 650 725 8021