I've now tried the following approach:
1. Close any database connection
2. Delete the local database
3. Move an older backup to it's place
4. Open the connection to the restored, local database
5. Kick off the sync process
6. Wait till the initial replication has completed
7. Purge all documents provided by the pull replicator
Unfortunately I'm stuck in the steps 6 + 7. It seems, the replicator does
not execute a full replication after restoring the database. Although the
*kCBLReplicationChangeNotification* gets called multiple times, it's always
printing that there are 0 *pendingDocumentIDs* that need a sync (see code
below).
But after killing the app and restart it from scratch, all documents get
synced from the server.
Any idea what's wrong?
The following method is waiting till the initial replication has completed
(registered to the *kCBLReplicationChangeNotification*):
func databaseReplicationChanged(notification: NSNotification){
guard let replication = notification.object as? CBLReplication else {
return
}
if let error = replication.lastError{
print(error)
NSLog(error.localizedDescription)
}
let replications = replication.localDatabase.allReplications()
var pendingDocumentIDCount = 0
var idleReplicationCount = 0
for repl in replications{
if let pendingIDs = repl.pendingDocumentIDs{
pendingDocumentIDCount += pendingIDs.count
}
if repl.status == .Idle{
idleReplicationCount++
}
}
print("pendingDocumentIDCount: \(pendingDocumentIDCount) -
idleReplicationCount: \(idleReplicationCount)")
if replications.count == idleReplicationCount && pendingDocumentIDCount ==
0 {
NSNotificationCenter.defaultCenter().postNotificationName(PersistenceManagerNotification.DatabaseCompletedReplication.rawValue,
object: replication.localDatabase)
}
}
This additional purge method, gets called from the
*PersistenceManagerNotification.DatabaseCompletedReplication *handler:
func databasePurgePulledDocuments(database: CBLDatabase) throws{
for repl in database.allReplications(){
if repl.pull {
if let documentIDs = repl.documentIDs{
print("documentIDs to delete: \(documentIDs)")
for documentID in documentIDs{
try database.deleteLocalDocumentWithID(documentID)
}
}
break
}
}
}
Am Sonntag, 22. November 2015 11:33:20 UTC+1 schrieb Brendan Duddridge:
>
> I forgot to add that I would think then the sync process could start from
> scratch, uploading the data from the client to the server. Basically the
> client gets to decide who the "source of truth" is in this circumstance.
>
> On Sunday, November 22, 2015 at 3:31:34 AM UTC-7, Brendan Duddridge wrote:
>>
>> Well that definitely complicates things. Perhaps another way to reset
>> back to a previous state would be to purge all the documents on the server
>> for a specific channel? Given that in my case a user can have multiple
>> cblite2 database files, each belonging to their own channel. And then
>> restore the cblite2 database file to a previous version?
>>
>> Thanks,
>>
>> Brendan
>>
>> On Saturday, November 21, 2015 at 11:39:51 PM UTC-7, Jens Alfke wrote:
>>>
>>>
>>> On Nov 21, 2015, at 7:19 PM, Brendan Duddridge <[email protected]>
>>> wrote:
>>>
>>> Are you implying in your response to this question that you can't just
>>> replace the cblite2 database package and that you must read through the
>>> backup file, restoring to the current database with the contents of the
>>> backup file? Does that mean that you would then also have to delete all the
>>> documents created since the most recent document in the backup database?
>>>
>>>
>>> Yes, *if* your purpose in backing up is to reset the database back to
>>> the state it was in at some past time (as opposed to just being able to
>>> restore the database later on in case of data loss.) In resetting back to a
>>> *past* state, you are fighting against the replicator, whose job it is
>>> to update to the *latest* state available on the server. That’s why you
>>> can’t just restore the database file — it contains old revisions that will
>>> be replaced by newer ones from the server.
>>>
>>> —Jens
>>>
>>
--
You received this message because you are subscribed to the Google Groups
"Couchbase Mobile" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/mobile-couchbase/d6588285-c29c-4fcb-b36a-732dc0b5c6ba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
