I think it actually works quite well for very small things (that is, < 10KB). I used this approach for small-ish user avatars as a UIImagePNGRepresentation()-backed transformable attribute on an original iPad.
-ev On Jul 21, 2011, at 00:29, Roland King wrote: > Oh I see what you mean. I've already done that as I said in the original > message, the audio piece is on a separate entity with a 1-1 relationship to > the actual entity which means I can keep it faulted out until I actually need > the audio (as opposed to needing the other various properties of the thing > which owns it), that audio data entity contains the data and nothing else. > I'm just trying to figure out whether sqlite is the best way to store that, > or if I should offload it to a file and just reference it, dealing with the > housekeeping. > > On Jul 21, 2011, at 12:24 AM, Evadne Wu wrote: > >> Good to know; keep in mind that FileBlob and Audio are entity names I >> conjured out of thin air and you will have to implement them. :) >> >> -ev >> >> On Jul 20, 2011, at 23:58, Roland King wrote: >> >>> Thanks - I'll look up FileBlob when I re-download all my tools .. I >>> upgraded to Lion and didn't think about the consequences! >>> >>> On Jul 20, 2011, at 11:46 PM, Evadne Wu wrote: >>> >>>> I still recommend files if the object is not very, very negligibly small, >>>> or if there is going to be hundreds of them. Core Data SQLite fetching is >>>> all-or-nothing — either you only have the object ID or the entire row is >>>> awaken from fault. You can use (for example) a FileBlob entity which is >>>> related to the Audio entity, though. >>>> >>>> -ev >>>> >>>> On Jul 20, 2011, at 19:50, Roland King wrote: >>>> >>>>> In my iOS app, using core data, one of my model objects is short audio >>>>> clips, 2-10 seconds worth of reasonably low quality mono audio. Not huge, >>>>> but not tiny either. Currently I'm using a binary property in my core >>>>> data model to store them. I've read the documentation and made sure the >>>>> audio clips are a separate entity with a 1-1 relationship so they can be >>>>> faulted in and out again, and I'm keeping some basic metadata about them >>>>> in my data object to avoid faulting them in until I really need the audio >>>>> (eg I keep the length of the clip in a separate property for display >>>>> without having to load the data. >>>>> >>>>> Does anyone have any insight into whether sqlite backing core data is an >>>>> efficient way to store binary data? However I store it it's going to take >>>>> space up in flash memory on the device, I know that if I offloaded it to >>>>> a file in the application's documents directory the file will be the >>>>> length of the data (plus a very small overhead), which is about as well >>>>> as I can do, but I'll have to deal with the housekeeping issues of making >>>>> sure core data and the filesystem are in sync, including after syncs, so >>>>> I'd like to just leave it in sqlite and let coredata worry about it; core >>>>> data is good at that stuff. >>>>> >>>>> Has anyone any experience of performance or space efficiency issues I'm >>>>> likely to run across doing it this simple way? eg if sqlite adds a large >>>>> overhead to BLOBs, I won't use it, or if it's insanely much slower than >>>>> pulling from a file, I won't use it and will do the work to store the >>>>> assets separately. >>>>> >>>>> Thanks >>>>> >>>>> >>>>> _______________________________________________ >>>>> >>>>> 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: >>>>> http://lists.apple.com/mailman/options/cocoa-dev/ev%40monoceroi.com >>>>> >>>>> This email sent to e...@monoceroi.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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
