Replication of databases with lazy table creation is not tested

[Richard Boulton]

Currently, there are no tests of replication when tables are created lazily; for example, consider the following situation.

• Database A is created, and some documents are added with no positional information (so no position.DB file is created)

• Database B is created by replication of A

• Database A has a new document with positional information added, so the position.DB file is created.

• Database B is then updated by replication.

I suspect that either the final replication will fail with an error due to not being able to find the table, or the position data will silently be lost.

Of a lower priority: I suspect that we will also have a failure in the situation where the positional information in a "master" database is deleted by a user (by removing the .DB and base files for the position lists), and a replication update is then performed: to fix this (such that the replicated child ends up without the position database) I think we would need to check for existence of the .DB files on the master at the end of each replication, and send a message if they are missing. I am not sure that supporting this is worthwhile.

I've not had time to look at writing a test for this - it's probably not very hard. Marking as 1.1.6 since I suspect this actually is a problem that needs fixing, rather than just a missing testcase for a feature which should work.

[Olly Betts]

Just to note what we discussed on IRC, it would be good to address this before 1.2.0, but it's not worth delaying the release for I feel. It's a bug in a new feature rather than a regression, and we should be able to fix it without a protocol change.

Also, I think we can just document the limitation about deleting an optional table not being handled by replication, at least for now. Supporting it would probably need an incompatible protocol change, but is hardly a release blocker. (Though perhaps you can send a "new file" for the removed file, with 0 size, meaning to remove it? The protocol document doesn't cover how the messages can validly occur together...)

[Olly Betts]

We're releasing 1.2.0 rather than 1.1.6, so marking this for 1.2.1 (at least for now).

[Richard Boulton]

Fixed in r14463. It turns out that there was indeed a bug here, but there was no need to change the replication protocol to address it - we just create the DB file if a changeset mentions it, and it didn't previously exist.