开发者

abort a fetchRequest in managedObjectContext

开发者 https://www.devze.com 2023-02-04 16:51 出处:网络
I have a fetchRequest which takes up to 4-5 seconds to finish. Since it is part of a search-as-you-type solution, is there any way to abort a fetchRequest?

I have a fetchRequest which takes up to 4-5 seconds to finish. Since it is part of a search-as-you-type solution, is there any way to abort a fetchRequest?

I use a timer set to start searching my database after 600ms after the user ended typing. So there is a possibility that a new search has to start before the old one has finished.

I haven't found any methods for the NSMangedObjectContext that seem to be right. Is simp开发者_如何学运维ly setting the old fetchRequest = nil the way to go? Or is there still something going on in the background?

Any ideas?

Thanks in advance!

PS: I'm also trying to enhance my query speed. Maybe someone has an idea for that too: https://stackoverflow.com/questions/4695729/query-performance-with-large-database


Better way is a place limit for fetch request objects.

  • (void)setFetchLimit:(NSUInteger)limit Parameters limit The fetch limit of the receiver. 0 specifies no fetch limit. Discussion

Special Considerations If you set a fetch limit, the framework makes a best effort, but does not guarantee, to improve efficiency. For every object store except the SQL store, a fetch request executed with a fetch limit in effect simply performs an unlimited fetch and throws away the unasked for rows.


Assuming you're using a UITextField for the text entry, why don't you move your fetchRequest logic to the textField:shouldChangeCharactersInRange:replacementString: (UITextField) delegate method?

This method is called every time a user enters or deletes a character from the textfield, so it is the perfect place to check for a minimum number of characters before firing off a fetch request, as well as changes to the text that would require you to set the existing fetchrequest to nil and start a new one.


I don't think you can, since it almost certainly ties up the thread doing the fetch. The last time I needed to do something like this, I spawned a background thread, with a basic condvar (NSCondition) to signal when a new input was available, and -performSelectorOnMainThread:... to signal when the output was ready. This means that the background thread will continue to work on out-of-date inputs for a while before picking up the new "most recent" input.

You can probably do a similar thing with NSOperation/NSOperationQueue by cancelling all operations on the queue (representing old inputs) before adding a new one (representing the latest input).

Since NSMO/NSMOC isn't thread-safe, you probably want to pass the set of (the first few) MOIDs instead.

0

精彩评论

暂无评论...
验证码 换一张
取 消