为什么我的NSFetchedResultsController加载所有行？

Question

我有一个NSFetchedResultsController，用于在表视图中显示数据（22117行）。 fetchBatchSize在fetchRequest上设置为20。它按预期工作：加载表视图时，只完全填充了20行。 SQL语句：

txt_Advance.Text = netAmount.ToString("$.00"); //will display $200.00
txt_Advance.Text = String.Format("{0:c}", netAmount); //will display currency symbol based on computer's culture setting

但是，我有另一种视图以不同的顺序显示相同的实体（只有几个实体通过谓词过滤）。我在这个视图中没有使用NSFetchedResultsController。如果我加载此视图，在managedObjectContext中加载了大约59个对象，然后重新加载另一个表视图，NSFetchedResultsController现在按20行批量加载所有行（22117）。这里是SQL语句（只有第一个）：

2015-06-12 17:59:55.526 BoulderFinder[2228:1220755] CoreData: sql: SELECT 0, t0.Z_PK FROM ZBOULDER t0 ORDER BY t0.ZNORMALIZEDNAME
2015-06-12 17:59:55.533 BoulderFinder[2228:1220755] CoreData: annotation: sql connection fetch time: 0.0070s
2015-06-12 17:59:55.534 BoulderFinder[2228:1220755] CoreData: annotation: total fetch execution time: 0.0075s for 22117 rows.
2015-06-12 17:59:55.534 BoulderFinder[2228:1220755]

2015-06-12 17:59:55.540 BoulderFinder[2228:1220755] CoreData: sql: SELECT 0, t0.Z_PK, t0.Z_OPT, t0.ZBOULDERDESCRIPTION, t0.ZFIRSTCLIMBERFIRSTNAME, t0.ZFIRSTCLIMBERLASTNAME, t0.ZGRADE, t0.ZIMAGE, t0.ZLATITUDE, t0.ZLONGITUDE, t0.ZNAME, t0.ZNORMALIZEDAREANAME, t0.ZNORMALIZEDCIRCUITNAME, t0.ZNORMALIZEDGRADE, t0.ZNORMALIZEDNAME, t0.ZNUMBERINCIRCUIT, t0.ZAREA, t0.ZCIRCUIT FROM ZBOULDER t0 WHERE  t0.Z_PK IN  (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)  ORDER BY t0.ZNORMALIZEDNAME LIMIT 20
2015-06-12 17:59:55.541 BoulderFinder[2228:1220755] CoreData: annotation: sql connection fetch time: 0.0010s
2015-06-12 17:59:55.541 BoulderFinder[2228:1220755] CoreData: annotation: total fetch execution time: 0.0014s for 20 rows.

我找到的唯一解决方法是在设置NSFetchedResultsController之前调用resetContext。

相关代码下方：

2015-06-12 18:00:23.315 BoulderFinder[2228:1220755] CoreData: sql: SELECT 0, t0.Z_PK FROM ZBOULDER t0 ORDER BY t0.ZNORMALIZEDNAME
2015-06-12 18:00:23.322 BoulderFinder[2228:1220755] CoreData: annotation: sql connection fetch time: 0.0067s
2015-06-12 18:00:23.322 BoulderFinder[2228:1220755] CoreData: annotation: total fetch execution time: 0.0070s for 22117 rows.
2015-06-12 18:00:23.323 BoulderFinder[2228:1220755] CoreData: sql: SELECT 0, t0.Z_PK, t0.Z_OPT, t0.ZBOULDERDESCRIPTION, t0.ZFIRSTCLIMBERFIRSTNAME, t0.ZFIRSTCLIMBERLASTNAME, t0.ZGRADE, t0.ZIMAGE, t0.ZLATITUDE, t0.ZLONGITUDE, t0.ZNAME, t0.ZNORMALIZEDAREANAME, t0.ZNORMALIZEDCIRCUITNAME, t0.ZNORMALIZEDGRADE, t0.ZNORMALIZEDNAME, t0.ZNUMBERINCIRCUIT, t0.ZAREA, t0.ZCIRCUIT FROM ZBOULDER t0 WHERE  t0.Z_PK IN  (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)  ORDER BY t0.ZNORMALIZEDNAME LIMIT 79
2015-06-12 18:00:23.324 BoulderFinder[2228:1220755] CoreData: annotation: sql connection fetch time: 0.0009s
2015-06-12 18:00:23.324 BoulderFinder[2228:1220755] CoreData: annotation: total fetch execution time: 0.0013s for 20 rows.
2015-06-12 18:00:23.324 BoulderFinder[2228:1220755] CoreData: sql: SELECT 0, t0.Z_PK, t0.Z_OPT, t0.ZBOULDERDESCRIPTION, t0.ZFIRSTCLIMBERFIRSTNAME, t0.ZFIRSTCLIMBERLASTNAME, t0.ZGRADE, t0.ZIMAGE, t0.ZLATITUDE, t0.ZLONGITUDE, t0.ZNAME, t0.ZNORMALIZEDAREANAME, t0.ZNORMALIZEDCIRCUITNAME, t0.ZNORMALIZEDGRADE, t0.ZNORMALIZEDNAME, t0.ZNUMBERINCIRCUIT, t0.ZAREA, t0.ZCIRCUIT FROM ZBOULDER t0 WHERE  t0.Z_PK IN  (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)  ORDER BY t0.ZNORMALIZEDNAME LIMIT 79
2015-06-12 18:00:23.326 BoulderFinder[2228:1220755] CoreData: annotation: sql connection fetch time: 0.0012s
2015-06-12 18:00:23.326 BoulderFinder[2228:1220755] CoreData: annotation: total fetch execution time: 0.0015s for 20 rows.
    ...

我无法理解这种行为。

编辑：

Answer 1

我已经使用简化的应用程序再次执行测试以确保行为。我有2个VC： - 在第一个中，我使用fetchBatchSize 20获取所有对象（22117）并访问结果的第一个元素 - 在第二个中，我获取了59个对象并修改了它们的瞬态属性

fetchRequest.includesPingndingChanges = YES

如果我加载第一个VC，则只有前20行完全加载：

2015-06-16 23:13:45.520 BoulderFinder[946:271012] CoreData: sql: SELECT 0, t0.Z_PK FROM ZBOULDER t0 
2015-06-16 23:13:45.528 BoulderFinder[946:271012] CoreData: annotation: sql connection fetch time: 0.0074s
2015-06-16 23:13:45.528 BoulderFinder[946:271012] CoreData: annotation: total fetch execution time: 0.0081s for 22117 rows.
CoreData: sql: SELECT 0, t0.Z_PK, t0.Z_OPT, t0.ZBOULDERDESCRIPTION, t0.ZFIRSTCLIMBERFIRSTNAME, t0.ZFIRSTCLIMBERLASTNAME, t0.ZGRADE, t0.ZIMAGE, t0.ZLATITUDE, t0.ZLONGITUDE, t0.ZNAME, t0.ZNORMALIZEDAREANAME, t0.ZNORMALIZEDCIRCUITNAME, t0.ZNORMALIZEDGRADE, t0.ZNORMALIZEDNAME, t0.ZNUMBERINCIRCUIT, t0.ZAREA, t0.ZCIRCUIT FROM ZBOULDER t0 WHERE  t0.Z_PK IN  (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)   LIMIT 20
2015-06-16 23:13:45.532 BoulderFinder[946:271012] CoreData: annotation: sql connection fetch time: 0.0012s
2015-06-16 23:13:45.532 BoulderFinder[946:271012] CoreData: annotation: total fetch execution time: 0.0021s for 20 rows.

现在，如果我加载第二个VC然后加载第一个VC，则所有行都按20个批次加载。

但是，如果我在不修改瞬态属性的情况下进行相同的测试，那么只有前20行完全加载。

最后，如果fetchRequest.includesPendingChanges = NO

忽略待处理的更改，然后在所有情况下都按预期工作。

奇怪，但这是它的工作原理。 感谢pbasdf。