[Biococoa-dev] More on CoreData

[John Timmer]

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

_______________________________________________
This mind intentionally left blank