On Oct 16, 2015, at 12:54 AM, Alexander Selling <[email protected]<mailto:[email protected]>> wrote:
It's the Push replicator that fails, and it gives up when it detects illegal keys such as _removed (which isn't illegal I know but cbl thinks it is, sometimes) Yes, that’s issue #776 that we fixed a few months ago and released in 1.1.1. (Oops, actually #671; #776 was the pull request for the patch.) I don't really have problems with purging besides it being buggy when being initiated from a background thread via the "tellDatabaseNamed", it has to be run from the main thread to be stable. Have you filed a bug report? And it just takes too long to complete when the database gets large, I do run it at every login but at a certain point it just takes too long. In 1.2 we’re enabling background auto-compact in ForestDB, so you won’t need to worry about compaction. (ForestDB in 1.1.x needs manual compaction, but I think it’s still faster than with SQLite.) Don't even get me started on what CBL does when you insert an illegal documentID :P If you want to pull your hair out, insert a documentID with (null) i.e. project_(null)_123456789 and then have SG assign that documentID as a channel, which breaks SGs naming convention for channels. That’s not an illegal document ID. It’s an illegal channel name, but those aren’t the same thing; using a docID as a channel name unmodified must be something your sync function did. Now there is no way you can fix this, CBL doesn't let you forget a document, purge only removes the json bodies not the documentID in the docs table. Whether there’s an entry in the docs table is irrelevant. The docs table is only a space-saving device that lets revisions refer to docIDs using a foreign key instead of a long string. If there is a bug where CBL keeps trying to push a purged document, please report it; I haven’t seen any issue like that come up. On the top of my wish list is to have a setting that makes the replicator just skip that specific document but still replicates all the other changes so that users don't lose all their data just because of one offending document. Alex, we can’t see your wish list. The real wish list for Couchbase Lite is the issue tracker on Github. And I think what you’re really asking for is fixes for issues that put a doc into a state that can break replication; again, please file bug reports if you want those fixed. (IIRC we fixed something like that in the past month or two, meaning the fix is in master and will be in 1.2.) —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/70C5913F-36F7-4C53-A54F-28ECFB843C5C%40couchbase.com. For more options, visit https://groups.google.com/d/optout.
