[OSM-dev] [OSM-talk] Oh dear - planet has duplicate id's

Tom Hughes tom at compton.nu
Sun Jun 3 13:34:26 BST 2007


In message <yekira9kxqa.fsf at dellow.uk.cyberscience.com>
          Tom Hughes <tom at compton.nu> wrote:

> In message <770592.96488.qm at web62501.mail.re1.yahoo.com>
>         Dan Moore <writetodan at yahoo.com> wrote:
> 
> > wow - and you know what, it's true - somehow there is no primary /
> > uniqueness constraint on that id:
> >
> > http://trac.openstreetmap.org/browser/sites/rails_port/db/create_database.sql#L69
> >
> > same goes for current_nodes - compare with current_ways (line 110)
> > which has appropriate primary key declaration.  i see you've filed a
> > ticket on this. perhaps we should move any further discussion to
> > dev at openstreetmap.org.
> 
> I was trying to make some sense of the schema last night, and I more
> or less gave up I'm afraid.
> 
> I was trying to make the ruby migration script (which is what we're
> apparently supposed to use to create OSM databases) match the schema
> from create_database.sql (which RichardF reckoned was more or less
> what was actually in use on the live system).

I now have a migration script which produces a schema that more or
less matches the create_database.sql script in the repository.

The only place where it doesn't match is two columns which have been
declared with an unsigned qualifier in the SQL script, and I propose
that we drop the qualifier from those - in at last one case other
columns that are logically the same type don't have the qualifier
anyway.

I would therefore like to propose a plan of action:

  1. Somebody dumps the actual schema from the live database so I can
     make sure it matches create_database.sql and correct anything in
     my migration script that doesn't quite match the live schema.

  2. Commit my fixed migration script and run an SQL script provided
     by me to drop those unsigned qualifiers from the live database
     so that the two are fully in sync.

  3. I produce a new migration script to migrate the database to a
     new schema version that fixes the missing unique indexes and
     any other oddidities in the current schema.

Comments?

Tom

-- 
Tom Hughes (tom at compton.nu)
http://www.compton.nu/




More information about the dev mailing list