[osmosis-dev] API 0.6 and unique keys

[Brett Henderson]

Frederik Ramm wrote:
> I was just importing 0.5 data into a 0.6 MySQL table via --migrate and 
> painfully learned that each duplicate key on input will abort the 
> whole process.
Yes, I wonder how the real migration will deal with this.  I guess it 
will just have to drop problematic relationships.
> The (hopefully, depending on ML settings) attached patch modifies the 
> --migrate task and associated test so that duplicate keys get silently 
> dropped. I'm happy to commit it myself if that's ok but it seemed to 
> me that ist was customary for Osmosis stuff to be discussed and then 
> applied by Brett.
I've started work on some developer docs.  I'll put in there a few of 
the key things I'm looking for when accepting patches.  If patches are 
in line with those key decisions and the code is reasonably easy to 
follow then I shouldn't have any issues with it.

I'm usually not too particular about task implementations because any 
problems with them are localised.  My main concern about the --migrate 
task will be that it is that it is runnable by those with minimal RAM.  
It's not a critical piece of functionality so I'm not too concerned 
about its implementation.

I'll take a look tonight, but if you want to commit it in the meantime 
it should be okay.

I want to find a balance between keeping the codebase to a reasonable 
and more importantly consistent standard and giving others enough 
flexibility to make required changes.  I'm not sure what the best way of 
doing that is yet.  I've been quite fussy up until now, I need to relax 
a bit :-)
> One could probably also have created a new --filter-duplicate-tags 
> task but since 0.5 does allow duplicates and 0.6 does not, it seems to 
> be a natural component of migration.
Would the existing 0.5 --bounding-box task do what you're looking for?  
If you run it without arguments it will select the entire planet, but 
will remove nodes from ways and members from relations that aren't 
recognised.  It's not an obvious way around the problem but might work.

Brett