Re: Uniquing data in Core Data
Re: Uniquing data in Core Data
- Subject: Re: Uniquing data in Core Data
- From: Rick Mann <email@hidden>
- Date: Thu, 15 Aug 2013 16:35:16 -0700
Doesn't work for sorting in NSFetchedresultsController
On Aug 15, 2013, at 16:34 , Sandor Szatmari <email@hidden> wrote:
> Can you make it a derived property? If each Managed object has a reference to the AppDelegate they can just return the comparison of their NSManagedObjectID to the one stored as the user default.
>
> Sandor Szatmari
>
> On Aug 15, 2013, at 1:07, Rick Mann <email@hidden> wrote:
>
>>
>> On Aug 14, 2013, at 21:14 , Jerry Krinock <email@hidden> wrote:
>>
>>>
>>> On 2013 Aug 14, at 20:46, Keary Suska <email@hidden> wrote:
>>>
>>>> A cleaner approach, IMHO, is to have a holder entity whose sole attribute is a to-one relationship to your other entity. Think of it as a singleton that always exist and maintains the particular managed object.
>>>
>>> Indeed Keary's idea is much better, and furthermore you may well already such an existing "singleton" entity nearby in that data model, which would be the logical place for this to-one relationship. Just add this relationship to that existing "singleton" entity.
>>
>> On Aug 14, 2013, at 20:46 , Keary Suska <email@hidden> wrote:
>>
>>> On Aug 14, 2013, at 6:28 PM, Rick Mann wrote:
>>>
>>>> I have a boolean property on an Entity for which only one should ever be true. Is it really bad to implement a custom setter that loads every other instance in the MOC that's true and sets them all to false? My code is actually good about always clearing the current one before setting the new one, but when I'm debugging, I will copy data over from another device, and it can't clear the old one in this case.
>>>
>>> I am not sure if it bad, but it sure smells funny ;-) Anyway, the issue may be more of the data approach. It is likely that the boolean attribute shouldn't belong to the entity at all--i.e. that the attribute is really for needed by some other object or process and is not a function of the entity. A cleaner approach, IMHO, is to have a holder entity whose sole attribute is a to-one relationship to your other entity. Think of it as a singleton that always exist and maintains the particular managed object. It also requires no code at all to maintain uniqueness--simply assign the relationship.
>>
>> Well, I used to store the active instance as a property of my app (AppDelegate). I'd store the NSManagedObjectID as a user default.
>>
>> Unfortunately, I need to be able to sort on the boolean property, and on an NSFetchedResultsController at that, which won't sort on transient properties.
>>
>> Moreover, it seems extraordinarily clumsy to have another entity representing the app, and to only have a singleton of that.
>>
>> --
>> Rick
>>
>>
>>
>>
>> _______________________________________________
>>
>> 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
--
Rick
_______________________________________________
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