• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Forcing Core Data to save attribute changed behind its back?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Forcing Core Data to save attribute changed behind its back?


  • Subject: Re: Forcing Core Data to save attribute changed behind its back?
  • From: Sean McBride <email@hidden>
  • Date: Wed, 25 Jul 2012 18:54:41 -0400
  • Organization: Rogue Research Inc.

On Tue, 24 Jul 2012 14:04:12 -0700, Quincey Morris said:

>I believe the answer is that you're Doing It Wrong™. :)

I know. :)  I only do it in one place, and only because the attribute is a few hundred MB, which I don't want to be copying all the time.

(The official Core Data recommendations for dealing with large BLOBs have always been very hand-wavy, with little-to-no framework support for their recommendations.  In 10.7 we now at least have the 'store in external record' option, but still no support for packages in NSPersistentDocument.  Despite me storing this large BLOB directly, performance is reasonable enough.  Besides, the app has shipped, and, barring migration, I can't change my model anyway.)

>For mutable values, you should either transfer ownership of the value
>to Core Data, or implement custom accessor methods to always perform a
>copy.

Which I always do for things like strings of few hundred bytes...

>Another way of saying all this is that it may not be possible to
>(reliably) inform Core Data that an attribute has changed without
>changing the identity of the object that represents the value.

:(  And changing the identity means using a different object... hmmmm... I guess since my object is basically a fancy wrapper of NSMutableData, I could actually copy my object but not copy the composed NSData too...

Cheers,

--
____________________________________________________________
Sean McBride, B. Eng                 email@hidden
Rogue Research                        www.rogue-research.com
Mac Software Developer              Montréal, Québec, Canada

_______________________________________________

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


  • Follow-Ups:
    • Re: Forcing Core Data to save attribute changed behind its back?
      • From: Kyle Sluder <email@hidden>
References: 
 >Forcing Core Data to save attribute changed behind its back? (From: Sean McBride <email@hidden>)
 >Re: Forcing Core Data to save attribute changed behind its back? (From: Quincey Morris <email@hidden>)

  • Prev by Date: Re: When does NSInputStream's -getBuffer:length: actually work?
  • Next by Date: Re: Forcing Core Data to save attribute changed behind its back?
  • Previous by thread: Re: Forcing Core Data to save attribute changed behind its back?
  • Next by thread: Re: Forcing Core Data to save attribute changed behind its back?
  • Index(es):
    • Date
    • Thread