> > I think you’re referring to issue #776 > <https://github.com/couchbase/couchbase-lite-ios/pull/776>? That was > fixed in 1.1.1. >
I'm not sure, if you look into the json body in the revs table lots of rows have _removed but the CBLLogger doesn't complain, it's only some documents where it fails to process them. I'll give it a try though! I sent you an email a while ago with some databases that will re-produce that as soon as you start a replicator connected to those databases. 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) > No, it doesn’t. You can purge without running a compact. > That's pretty cool news! I'll try that right away, I've never gotten that to work before. I usually keep the revs table up and look at the json bodies and they only disappear after a purge, but I'm probably just doing something wrong. > If you don’t compact, the database storage will grow continuously, which > is bad. Can you describe the problem you’re having with compaction? > 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. 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. > > Please don’t grope into the SQLite database, since there’s no limit to > what could go wrong. Obviously we can’t stop you, but we’re not going to > offer help. If you want to make significant changes or additions to what > CBL can do, it would be better to add them as new features in CBL itself. > I won't need to once the CBLReplicator doesn't die from _removed being flagged as an illegal key, I would prefer to stay as far away as possible from the underlaying storage mechanisms. 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. 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. So your user is now completely disabled from syncing because it keeps getting HTTP 500 back from SG, and errors/warnings always kills the replicator. 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. The only way to fix this is to rename the docid in the doc table, which of course is super easy since I have write access to it, as opposed to the revs table. It's obviously my fault that I'm inserting project_(null)_123456789 instead of project_projectName_123456789 but when things go wrong it shouldn't be impossible to fix it (which it wasn't in this case, the _removed key getting flagged as illegal however was) > I don’t know; you could try it easily enough. The latter is equivalent to > doing a push replication into a new empty local database. > True that! But if I can get purge to work without a compact this will be a non-issue! -- 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/f033612e-b5f6-44cc-abf1-65f5623a32c4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
