Is there a way to do an asynchronous fetch request against Core data returning partial results?
That depends on whether it's the query part that's expensive (e.g. WHERE clause with complex text searching and table scans) or simply the quantity of the row data that's your problem. For the latter, you can just use -setFetchBatchSize: and be done.
You can use a separate MOC on a background thread to perform asynchronous work. You can then pass over results to the main thread to display to the user. However, unless your search terms are very expensive, it's usually easier and faster to use -setFetchBatchSize: synchronously. For well indexed queries, it can handle a million or two rows per second. Not sure why you'd subject your users to that kind of experience. It's common to use fetch limits, count requests, and only show the top N results. What's your user going to do with a hundred thousand results anyway ?
If you need to attack the computational expense of your query terms, that's more complicated. Obviously it would be best to optimize the queries and ensure they are using an index. But if that's not enough, you can execute the queries in a background MOC, fetching objectIDs + row data (put in the the row cache) and then have the other MOC materialize the objects by ID from the row cache. There's a BackgroundFetching example in /Developer/Examples/CoreData. It shows how to do this. Returning partial results incrementally would require some creativity on your part to subdivide the query into several. Since most expensive queries are text searches, it's usually possible to subdivide the result set naturally. Like the first letter of 'title'. Similar to the thumb bar index on the side of the Contacts app on the iPhone.
There's also a DerivedProperty example on ADC for optimizing text queries.
Obviously, Apple's own Spotlight could not use something like Coredata, since it heavily relies on returning asynchronous partial results.
Which is neither here nor there. Most Cocoa applications wouldn't want Spotlight to be the sole persistence back end of their data. The latency of putting all your data in a full text index instead of a relational database or keyed archive would be pretty absurd. Now, if you're writing an app that's primarily structured around full text searching, you might instead prefer to focus on putting your data in Spotlight via small files, and using the Spotlight APIs. But it's not suitable for apps interested in an OOP view of their data.
Frankly, this is my second application I've attempted to use Coredata to find it come up surprisingly short. The first time the issue was core data not being thread safe.
Core Data can be used efficiently with multiple threads. It might help to think of each MOC as a separate writeable view. If you'd like to know more, you can search the archives for my posts.
What is the target market for Core Data? Why sort of application is ideal for its use? What size data store? Right now it escapes me.
Cocoa and Cocoa Touch applications, particularly done in an MVC style with an OO perspective on their data. Some people also use it as a persistent cache for data stored in another canonical format, such as XML files. On the Mac side, we've had customers with 3+ million rows (multi GB) databases, and on the embedded side, roughly 400,000 rows (100s MB). However, it does take some care and feeding to handle data sets like that, and most developers find it straight forward up to about 10% those numbers.
It sounds like you're having performance issues. What kinds of queries are you trying to accomplish ? How much data are you working with ? How have you modeled your primary entities?
You can fetch back just NSManagedObjectIDs, and - setIncludesPropertyValues: to NO to effectively create your own cursors if you prefer.
- Ben _______________________________________________ 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
