On Thu, Nov 27, 2008 at 3:39 AM, Brett Henderson <[EMAIL PROTECTED]> 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 _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
