[Biococoa-dev] More on CoreData

[John Timmer]

> 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.
Well, I thought this part was under NDA, but it's all over the Cocoa-dev
mailing list now, and the list-mom hasn't cut in to stop it.  The problem is
that relationships to other objects are stored in sets.  You have to do all
the management if you want to order them.  For example, to make a sequence
array, you'd have to insert a "holder" object that contains a position value
and a reference to the appropriate symbol, and then re-create the array when
you woke the sequence out of the store.

See below for some thoughts on using NSCoding for the array.

> 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?
For any simple values, you can just treat any Core Data object as a
dictionary, using "valueForKey" and "setValue:forKey:" as setters and
getters.  Since named methods get tried first, you can override the default
behavior simply by making an NSManagedObject subclass and handling specific
values with "myValue" and "setMyValue:"  methods.

You can use that to handle some more elaborate behavior.  For example, you
can have a value that's "dateOfBirth", and use that in a "ageInWeeks" method
without having to create a new value.  You can also have a "notesAsRTF"
value which holds NSData, and then a "notesString" method that extracts only
the NSString using the data.  NSCoding would work the same way, including
for arrays, as long as you don't need to preserve relationships to objects
in the coded ones.

> 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?
There's several ways I could imagine doing it - ranging from making
everything a core data object to just making BCSequence one.  That actually
may be the best way to handle it.  It would actually help make the features
work, as a feature could easily refer to the specific sequence, and all that
could be preserved between saves.  Since we already have easy methods for
storing/retrieving the actual sequence as strings and sequence types as
ints, it becomes fairly easy to store things as strings/scalars, and still
provide a BioCocoa face to the world.

This might allow us to make a specialized NSManagedObject class for pre-10.4
systems that handles saving to files in a way that's analogous to CoreData.
Since we only need to get it to work for a single class, it might be
relatively painless.



_______________________________________________
This mind intentionally left blank