Re: Uniquing data in Core Data
Doesn't work for sorting in NSFetchedresultsController On Aug 15, 2013, at 16:34 , Sandor Szatmari 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 wrote: > >> >> On Aug 14, 2013, at 21:14 , Jerry Krinock wrote: >> >>> >>> On 2013 Aug 14, at 20:46, Keary Suska 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 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 (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/admin.szatmari.net%40gmail.com >> >> This email sent to admin.szatmari@gmail.com -- Rick ___ 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
Re: Uniquing data in Core Data
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 wrote: > > On Aug 14, 2013, at 21:14 , Jerry Krinock wrote: > >> >> On 2013 Aug 14, at 20:46, Keary Suska 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 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 (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/admin.szatmari.net%40gmail.com > > This email sent to admin.szatmari@gmail.com ___ 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
Re: Uniquing data in Core Data
On Aug 14, 2013, at 21:14 , Jerry Krinock wrote: > > On 2013 Aug 14, at 20:46, Keary Suska 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 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 (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
Re: Uniquing data in Core Data
On 2013 Aug 14, at 20:46, Keary Suska 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. ___ 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
Re: Uniquing data in Core Data
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. HTH, Keary Suska Esoteritech, Inc. "Demystifying technology for your home or business" ___ 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
Uniquing data in Core Data
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. -- Rick ___ 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
