Re: Core Data or not
Re: Core Data or not
- Subject: Re: Core Data or not
- From: Andy Lee <email@hidden>
- Date: Sun, 07 Aug 2016 00:45:16 -0400
On Aug 6, 2016, at 12:13 PM, Trygve Inda <email@hidden> wrote:
>
>> On Aug 6, 2016, at 1:46 AM, Trygve Inda <email@hidden> 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 (email@hidden)
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:
This email sent to email@hidden