2016-03-15 140 views
0

這個問題曾被問過很多次,但我一直無法找到完整的答案。我需要使用sqlite3數據庫將數據存儲在我的應用程序中,而核心數據不是一個選項。我想使用iCloud在設備之間同步數據,最好的辦法是將SQL事務日誌發送到iCloud並使用它們使設備保持最新狀態。我想出了到目前爲止的過程如下:與iCloud同步SQLite3數據庫

  • 所有的數據庫查詢改變(INSERT,UPDATE,DELETE)執行一次存儲在交易陣列,其中的每個元素包含SQL查詢和戳它進行
  • 數據庫包含表記錄的交易陣列的應用終於趕到了(包括存儲在iCloud上的交易文件的文件名)
  • 交易陣列保存到設備唯一的文件中的點在iCloud上
  • 同步時:
    1. 獲取的交易文件陣列從iCloud中
    2. 創建要致力於
    3. 對於每個文件交易的空數組:
      • 檢查數據庫的最後位置在交易文件
      • 如果有到無,開始從文件開始
      • 從該點添加每筆交易的交易的陣列將被提交
      • 與交易文件中新的最後位置,因此T更新數據庫他同步交易不重複
    4. 排序交易的陣列通過交易時間戳致力
    5. 交易的陣列將被提交

我相信,在執行命令我可以通過將數據下拉到每個設備並執行命令更新每個本地副本來實現這一目標。我設想的唯一問題是,如果兩臺設備在離線和同步時都向同一張表插入記錄。例如:

  1. 裝置1和裝置2都在表中「TABLE1」
  2. 裝置1點的插入值「foo」的已同步的數據庫的副本,其中每個四個記錄到表「表1」與PK 5
  3. 設備2個插入值「欄中的」表「表1」與PK 5
  4. 設備1個下載事務日誌裝置2和插入值「欄」 ID 6
  5. 設備2個下載事務日誌裝置1和將值「foo」插入ID 6

我們現在有一種情況,這些記錄的主鍵在每個設備上都是反轉的,這會斷開鏈接到依賴主鍵進行鏈接的表。

我仍然試圖研究一個解決方案,但在此期間,如果任何人有建議,我將非常感激!

回答

0

我一直在想這一整天,我想我已經想出了一個解決方案。我在這裏發佈,看看有沒有人有任何意見,我明天就會去實施它。

我的想法是取消自動增量整數主鍵,並用基於字符串的鍵替換它。密鑰將從設備的UUID和時間戳中生成。這意味着密鑰是特定於設備並且行是唯一的。所以,從上方使用該方法(使用爲了便於閱讀簡化鍵字符串)改寫的INSERT例如:

  1. 裝置1和裝置2兩者都同步的數據庫的副本,與四個記錄每個表中的「表1"
  2. 裝置1點的插入值‘foo’的表‘表1’與PK‘ABC123’
  3. 設備2個插入值‘欄中的’表‘表1’與PK‘def456’
  4. 設備1個下載事務日誌爲設備2插入值「bar」到ID「def456」
  5. 設備2下載事務日誌對於設備1,並將值「foo」插入到ID「abc123」

這可用,因爲設備知道事務將導致插入使用設備特定值鍵入的行。因此插入操作後鍵列中沒有重複值的危險。

對這種方法的任何想法都會受到歡迎!

UPDATE 我將此標記爲正確的答案,因爲它工作。以下是我如何修改現有數據庫(和應用程序)以允許跨設備同步。幸運的是,這還不是一款生產應用程序,因此對數據庫所做的重大更改並未造成問題。

  1. 全部更改數據庫表使用文本類型的列作爲其主鍵
  2. 添加一個「最後的指標」表中,其上的凸起的表名和具有另外一個欄,顯示的索引號數據庫添加到該表中的最後一行
  3. 嚮應用程序添加了一種方法,該方法通過檢索表格的最後一個插入索引並將其遞增1來生成設備和行唯一TEXT關鍵字,然後添加到該設備UUID。
  4. 插入任何行時,將調用(3)中描述的方法以獲取將記錄插入數據庫的適當密鑰
  5. 所有數據庫修改函數都會將SQL查詢添加到事務日誌中,每個其中入境也是日期和時間標記和使用設備的UUID作爲其文件名保存到本地文件
  6. 設備的本地事務日誌,然後推到iCloud
  7. 同步處理涉及以下內容:
    • 下載來自iCloud的所有交易日誌
    • 忽略設備自己的事務日誌,查看每個日誌中的SQL命令列表,並將它們添加到命令數組中,從最後一次同步的日誌的索引號開始
    • 存儲索引編號在完成了用於日誌數據庫中,以便同一命令不會在下次同步重新執行
    • 排序所有SQL的陣列按日期從所有日誌命令
    • 執行以便
的命令

關於即時通訊在這個過程中,我已經得到了第5步。沒有一個iCloud特定的東西已經實現。但是,我已通過在運行應用程序副本的設備之間手動複製事務日誌來測試該過程,並且我可以確認該過程正常工作。包含設備的UUID的TEXT主鍵確保不發生衝突。所有設備都可以插入對方的數據,並且密鑰始終是唯一的。

這樣做的缺點是,該數據庫將更大(因爲鍵不是整數更長),並且有大量涉及字符串比較的查詢可能需要更長的時間。但是,我使用的數據庫相對較小,每個用戶交互只有幾個查詢,所以我不會在這裏預見到問題。

我希望這對其他誰來一起相同的問題是有用的:)