中止 ManagedObjectContext 中的 fetchRequest

发布于 2024-10-12 01:15:45 字数 503 浏览 4 评论 0原文

我有一个 fetchRequest 需要 4-5 秒才能完成。由于它是“即输入即搜索”解决方案的一部分,是否有任何方法可以中止 fetchRequest?

我使用计时器设置在用户结束输入 600 毫秒后开始搜索数据库。因此,有可能在旧的搜索完成之前必须开始新的搜索。

我还没有找到任何似乎正确的 NSMangedObjectContext 方法。简单地设置旧的 fetchRequest = nil 是可行的方法吗?还是背后还有什么事情在发生?

有什么想法吗?

提前致谢!

PS:我也在努力提高我的查询速度。也许有人也有这样的想法: https://stackoverflow.com/questions/4695729/query-performance-with-large-database< /a>

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 simply 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

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

稍尽春風 2024-10-19 01:15:45

更好的方法是对获取请求对象进行位置限制。

  • (void)setFetchLimit:(NSUInteger)限制
    参数
    限制
    接收器的获取限制。 0 指定没有获取限制。
    讨论

特别注意事项
如果您设置提取限制,框架会尽最大努力(但不保证)提高效率。对于除 SQL 存储之外的每个对象存储,在有效的提取限制下执行的提取请求只会执行无限制的提取并丢弃未请求的行。

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.

生寂 2024-10-19 01:15:45

假设您使用 UITextField 作为文本输入,为什么不将 fetchRequest 逻辑移至 textField:shouldChangeCharactersInRange:replacementString: (UITextField) 委托方法呢?

每次用户在文本字段中输入或删除字符时都会调用此方法,因此它是在发出获取请求之前检查最小字符数以及需要您更改文本的最佳位置将现有的 fetchrequest 设置为 nil 并启动一个新的。

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.

无声情话 2024-10-19 01:15:45

我认为你不能,因为它几乎肯定会占用执行获取的线程。上次我需要做这样的事情时,我生成了一个后台线程,其中有一个基本 condvar (NSCondition) 用于在新输入可用时发出信号,以及 -performSelectorOnMainThread:... 在何时发出信号输出已准备就绪。这意味着后台线程将继续处理过时的输入一段时间,然后再获取新的“最新”输入。

您可以通过在添加新操作(表示最新输入)之前取消队列上的所有操作(表示旧输入),对 NSOperation/NSOperationQueue 执行类似的操作。

由于 NSMO/NSMOC 不是线程安全的,因此您可能希望传递一组(前几个)MOID。

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文