2

私たちのアプリでは、ネットワーク/電子メールを介して部分的な Core Data SQLite データベースの共有を実装しています。ファイルサイズを小さく保つために、Core Data データベースを圧縮する以下の方法を実装しました。

    - (void) shrinkDB
    {
        sqlite3 * database;
        NSString * string = [shareStoreURL path];
        const char * filename = [string cStringUsingEncoding:[NSString defaultCStringEncoding]];
        char *errMsg;
        if (sqlite3_open(filename, &database) == SQLITE_OK)
        {
            NSLog(@"Shrinking...");
            if (sqlite3_exec(database, "VACUUM;", NULL, NULL, &errMsg) != SQLITE_OK)
            {
                NSLog(@"Failed execute VACUUM");
            }
            sqlite3_close(database);
         }
        }

質問: 上記のコードはデータベースを縮小します。しかし Apple は、Core Data の実装の詳細はいつでも変更される可能性があると述べています。近い将来、この方法を使用しても安全だと思いますか? または、他に良い解決策はありますか？

4

2 に答える 2

5

これを行う適切な方法は、NSSQLiteManualVacuumOption を永続ストア コーディネーターに与えることです。

ドキュメントからのスニペット:

NSSQLiteManualVacuumOption

ストア ファイルを再構築するためのオプション キー。ストアがコーディネーターに追加されたときに、データベース全体の最適化を強制します。これにより、SQLite の VACUUM コマンドが呼び出されます。SQLite ストア以外のストアでは無視されます。OS X v10.6 以降で利用できます。NSPersistentStoreCoordinator.h で宣言されています。

これを参照してください: https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/CoreDataFramework/Classes/NSPersistentStoreCoordinator_Class/NSPersistentStoreCoordinator.html

于 2012-08-05T23:50:06.560 に答える
2

AppleがSQLiteデータベースで永続データを構築する方法は、実装の詳細であり、変更される可能性があります。ただし、SQLiteが削除されたレコードを管理する方法は、Appleの実装とは無関係です。

そうは言っても、SQLiteデータベースをバキュームするプロセスは、データベース全体を再構築する結果になります。これは、sqliteファイルがCoreDataNSPersistentStoreCoordinatorによって使用されている場合に悪影響を与える可能性があります。

あなたの場合、変更を保存した後、電子メールで送信する前に掃除機をかけたいようです。NSSQLiteManualVacuumOptionオプションを使用すると、SQLiteファイルが最初に開かれたときにのみDBがバキュームされるように見えます。

ファイルがNSPersistentStoreCoordinatorに関連付けられなくなった後で上記のコードを実行するか、NSSQLiteManualVacuumOptionを使用してファイルを再度開いて閉じてから、電子メールで送信します。

もう1つのオプションは、Base on OS Xなどの外部SQLiteツールを使用して、ファイルを手動でバキュームすることです。過去にFirefoxSQLiteマネージャー拡張機能も使用しました。

于 2012-08-06T00:11:23.077 に答える