根据瞬态计算值查询核心数据存储
我对核心数据更复杂的部分还很陌生。
我的应用程序有一个包含 15K 行的核心数据存储。有一个单一的实体。
我需要在根据计算的搜索条件过滤的表视图中显示这些行的子集，并为显示的每一行添加一个我实时计算但不存储在实体中的值。
计算需要使用用户提供的几个值。
假设示例：
实体：包含字段“id”、“first”和“second”
用户输入：10 和 20
搜索/过滤条件：仅显示实体字段“id”是两个提供的数字之间的质数的记录。 （我假设我需要在这里构建某种复杂的谓词方法？）
显示：满足条件的所有记录的所有字段，以及派生字段（不在核心数据实体中），即“id”的总和”字段和一个随机数，因此表视图中的每一行将包含 4 个字段：
“id”、“first”、“second”、-计算值-
从我的阅读/谷歌搜索看来，瞬态属性可能是去吧，但我不知道怎么去考虑到搜索条件和结果属性需要根据用户输入进行计算，请执行此操作。
谁能给我任何指示来帮助我实现这段代码？我现在很迷茫，我在书本等中找到的例子并不能很好地满足我的特殊需求，以至于我无法据我所知来调整它们。
谢谢达伦
。
I'm fairly new to the more complex parts of Core Data.
My application has a core data store with 15K rows. There is a single entity.
I need to display a subset of those rows in a table view filtered on a calculated search criteria, and for each row displayed add a value that I calculate in real time but don't store in the entity.
The calculation needs to use a couple of values supplied by the user.
A hypothetical example:
Entity: contains fields "id", "first", and "second"
User inputs: 10 and 20
Search / Filter Criteria: only display records where the entity field "id" is a prime number between the two supplied numbers. (I need to build some sort of complex predicate method here I assume?)
Display: all fields of all records that meet the criteria, along with a derived field (not in the the core data entity) that is the sum of the "id" field and a random number, so each row in the tableview would contain 4 fields:
"id", "first", "second", -calculated value-
From my reading / Googling it seems that a transient property might be the way to go, but I can't work out how to do this given that the search criteria and the resultant property need to calculate based on user input.
Could anyone give me any pointers that will help me implement this code? I'm pretty lost right now, and the examples I can find in books etc. don't match my particular needs well enough for me to adapt them as far as I can tell.
Thanks
Darren.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您需要做的第一件事是停止考虑字段、行和列，因为这些结构实际上都不是核心数据的一部分。在这种情况下，这一点很重要，因为 Core Data 支持任意复杂的获取，但 sqlite 存储不支持。因此，如果您使用 SQLite 存储，您的提取将受到 SQLite 支持的限制。
在这种情况下，针对 SQLite 的谓词无法执行复杂的操作，例如计算属性值是否为素数。
第一种情况的最佳解决方案是添加
isPrime的布尔属性，然后修改id属性的 setter 来计算设置的 id 值是否为素数然后相应地设置isPrime。这将存储在 SQLite 存储中，并且可以针对例如isPrime==YES &&((first<=%@) && (second>=%@))进行获取第二种情况只是使用瞬态属性，您可以为其提供自定义 getter，以在托管对象位于内存中时计算其值。
一个经常被忽视的选项是不使用 sqlite 存储，而是使用 XML 存储。如果数据量相对较小，例如几千个文本属性，总内存占用量为几十兆，那么 XML 存储将非常快，并且可以处理更复杂的操作。
SQLite 有点像 Core Data 中发育不良的继子。它对于大数据集和低内存很有用，但随着内存变得越来越充足，它失去了优势。我发现这些天我自己用得越来越少了。您应该考虑在这种特殊情况下是否需要 sqlite。
The first thing you need to do is to stop thinking in terms of fields, rows and columns as none of those structures are actually part of Core Data. In this case, it is important because Core Data supports arbitrarily complex fetches but the sqlite store does not. So, if you use a sqlite store your fetches are restricted those supported by SQLite.
In this case, predicates aimed at SQLite can't perform complex operations such as calculating whether an attribute value is prime.
The best solution for your first case would be to add a boolean attribute of
isPrimeand then modify the setter for youridattribute to calculate whether the set id value is prime or not and then set theisPrimeaccordingly. That will be store in the SQLite store and can be fetched against e.g.isPrime==YES &&((first<=%@) && (second>=%@))The second case would simply use a transient property for which you would supply a custom getter to calculate its value when the managed object was in memory.
One often overlooked option is to not use an sqlite store but to use an XML store instead. If the amount of data is relatively small e.g. a few thousand text attributes with a total memory footprint of a few dozen meg, then an XML store will be super fast and can handle more complex operations.
SQLite is sort of the stunted stepchild in Core Data. It's is useful for large data sets and low memory but with memory becoming ever more plentiful, its loosing its edge. I find myself using it less these days. You should consider whether you need sqlite in this particular case.