■

UITableViewDataSource#moveRowAtIndexPath内でRe-Orderしたりしてコミットするケースにて。
このタイミングでトリガ弾かれて再描画が走ると、もう画面は大変なことに。
なので、以前はDB処理中に再描画が走らないようフラグ管理していたのですが、さすがにこの実装は糞過ぎるだろうと。
もはや、Move時のNSFetchedResultsControllerDelegateの存在理由がないだろうという実装。NSFetchedResultsChangeMoveでなんか、一生処理されない。
まー、UI上でMoveし終わったタイミングでmoveRowAtIndexPathが呼ばれるので、後にUITableViewにdeleteRowsAtIndexPathsやinsertRowsAtIndexPathsを発行する必要もないです(この処理自体が画面が壊れる原因)。
では、何故にテンプレコードが存在するのか。というか、彼らが邪魔する。恐らく、ポイントはmoveRowAtIndexPathでの実装というかセオリーがあるのだろうけど。
んー解せない。
実際に、moveRowAtIndexPathで何も行わないでいると、当然、didChangeObjectがNSFetchedResultsChangeMoveで呼び出されず、画面上では何の不具合もなくMoveが行えている。Re-Order処理していないのでリフェッチすると、元に戻るけど。ということは、やはりUI上でのMove処理は完結しているので、NSFetchedResultsChangeMoveでUITableViewを弄る必要がないという結論に到達する。
んー解せない。
これは思うに、UITableViewとNSFetchedResultsControllerの同期設計思想を理解していないと解けないと思う。
宿題。
ムジュラやろー

尼で購入する時に「発送は1〜3ヶ月以内」と表記されたのを流し読みして、後で奥さんに笑い話で「尼がバグってたよ。発送1〜3ヶ月て死活問題じゃんな。終わってるじゃんな。あれ、%日のフォーマットをバグらせて%ヶ月にしてしまっているんだろうな」て。したら、いつまで経っても到着しないのでアカウントサービスで確認すると、ガチで1〜3ヶ月でした。
こんな商品もあるのですね(予約品ではないです)。
またしても先入観に敗北。

CoreDataを用いている場合、とある条件に一致するレコードを一括して削除する操作を以下の手順で組んでいる。
1. 条件にヒットするレコードをNSFetchRequestで検索
2. 検索結果のオブジェクト配列をループ
2.1 NSManagedObjectContext#deleteObjectを発行
3. ループ終えたらNSManagedObjectContext#saveを発行しコミット
要は1レコードずつのDELETE発行になる訳ですが、トランザクションで考えるとアホか！となる訳です。いや、コミットはすべてのDELETE発行後だから問題ないです。パフォーマンスの問題です。
DELETE FROM {TABLE} WHERE {とある条件}的なSQLが発行されるCoreDataの使い方を知らないが故。
最悪、NSManagedObjectContext#deleteObjectsてのがあれば良いと思いましたが、仮に存在しても内部的には1レコずつになるでしょう。
想像に任せて、NSDeleteRequestてのがあるのでは！とインテリジェンス掛けてみましたがありません。CoreDataのPDFを食い入るように眺めている訳ではないので、まだまだ未知なる機能があることでしょう。先日、SUM発行する際に「おぉお！こんな機能が！」て発見があったばかりですから。