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
