On Aug 6, 2016, at 12:13 PM, Trygve Inda <cocoa...@xericdesign.com> wrote:
>
>> On Aug 6, 2016, at 1:46 AM, Trygve Inda <cocoa...@xericdesign.com> wrote:
>>> For example, I would need to add items with ID# 204, 765, 983, 124, and 458
>>> to the array. This seems like with Core Data it would be 5 different
>>> fetches. Or is there some efficient way to fetch these 5 items in one
>>> request?
>>
>> You could add an entity to your data model that represents the custom
>> collection. It would have an attribute that is a one-to-many relationship to
>> InterestingObject. If you only have one of those manually-constructed
>> tables,
>> your data store would only contain one instance of this entity. That's
>> perfectly okay.
>>
>> --Andy
>>
>>
>
> I can't do that at run time though. I need the user to be able to build
> custom collections (like a custom iTunes playlist) that is a subset of the
> full collection but not by any simple predicate criteria.
You can certainly do it at runtime. Core Data allows your program to
manipulate object graphs and save the changes. It would be very weak indeed if
it could not model arbitrary collections of objects that the user can modify
and save.
To clarify my suggestion:
Presumably your data model will have an InterestingObject entity, and you'll
specify the InterestingObject class as the class for that entity. ("Entity"
and "class" are related but separate concepts in Core Data.)
You seem to be envisioning that your data model ONLY has that one entity.
I am suggesting you add another entity, something like CustomAlbum, with
presumably a corresponding class also named CustomAlbum. The CustomAlbum
entity would have a one-to-many relationship to the InterestingObject entity,
called something like interestingObjects. You can put any InterestingObjects
you want into an album's interestingObjects collection, whether
programmatically or in response to user input, and of course you can save
changes to the album.
I second the suggestions others have made to create a "play" project using Core
Data, either from scratch or as an experimental, purely educational fork of
your existing project. You will learn much more efficiently what you can and
cannot do, and you will get a better sense of whether you want to change how
your app manages its data.
I would echo Graham Cox's question about what your motivation is. If your
goals do not include getting generally familiar with Core Data -- I mean, if
you don't have an urgent reason to learn Core Data except for this project --
then maybe you don't have a strong reason to convert the app. 5000 objects
doesn't sound like much (depends on the objects, of course), and it sounds like
you are already comfortable loading them all into memory. So maybe, as Graham
says, "IIABDFI".
But maybe you anticipate your app's needs will scale far beyond 5000? Or maybe
you want some of Core Data's other features beyond straightforward object
persistence? Or maybe you anticipate your object model will grow more complex,
and you want to use the Core Data model editor to help visualize that? Or
maybe you're thinking a Core Data approach will reduce the learning curve for
new developers, who could use their existing knowledge of Core Data instead of
having to learn your current persistence mechanism? You haven't said, so we
can only guess.
--Andy
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
