[OSM-dev] Data corruption :) II

[Stefan de Konink]

On Wed, 26 Nov 2008, Frederik Ramm wrote:

> I cannot see the logic behind this.

The logic is terribly easy; if the current tables differ from the history.
It is clearly the current tables we would like to have in the planet
file, especially for ways. Now ways were not the only thing that went
fubar, but in relations it was clearly a major difference.

> You will not be able to force
> consistency onto 0.5; if your software cannot work with inconsistencies
> then it cannot work with the dumps/diffs we produce until 0.6. So either
> you find a way to handle these things on your side, or you will not be
> able to run your software until 0.6 anyway. Even if you do a mass change
> now to fix the existing inconsistencies, each day will produce new ones,
> and your software will fall over. Unless you find a way to deal with the
> inconsistencies, in which case you'd have to tell us why exactly 15k
> inconsistencies are "not acceptable" while a few hundred are.

Then let me even get a better proposal; A second machines will be
installed that has enforced foreign keys. This second machine will produce
the planet. And will directly trigger events upon corruption so the main
API doesn't need to cope with them until 0.6.


Stefan