[OSM-dev] Data corruption :) II

[Matt Amos]

On Thu, Nov 27, 2008 at 3:39 AM, Brett Henderson <brett at bretth.com> wrote:
> But I'm curious why you would ever need to know if an id has existed?

to give the client the distinction between 404 not found and 410 gone.
410 implies that a history call will work, 404 implies that it won't.

> I don't understand why deleted items are stored in the current tables.

its probably historic. it seems the current tables are just manually
maintained views of "select * from (select id, max(version) from
(nodes|ways|relations) group by id) as A join (nodes|ways|relations) B
on A.id=B.id".

>  From an osmosis perspective I've never had a need to know this type of
> thing. Full information will always be in the history table anyway and
> an attempt to use an id that has been used in the past will result in a
> primary key violation due to version 1 already existing. Perhaps this is
> not how rails works ...

rails relies on mysql's auto_increment or postgres' sequence
functionality to ensure no ids are used twice. the question is one of
practicality: if we take deleted elements out of the current tables
then we get an advantage (foreign key constraints ensure that no
way/relation can refer to a deleted node/member) and a disadvantage
(to keep api return codes the same we potentially need to examine both
the current and history tables).

as dave has already pointed out, the transactions introduced in 0.6
should give us the advantage without the disadvantage, as long as we
put checks inside the transaction to let the db know we need
repeatable reads.

if we can live with 404 meaning "doesn't exist in current", rather
than "has never existed", and drop the 410 response code then the
disadvantage goes away. but thats obviously a decision that needs
discussion :-)

cheers,

matt