[OSM-dev] Deriving Change Sets

Brett Henderson brett at bretth.com
Fri Jun 29 14:17:23 BST 2007

Tom Hughes wrote:
> I don't know what the history of this is - presumably it is just that
> ways were created later by which time somebody thought that an
> explicit version was better? or was it just the need to join to
> the tag and segment tables that led to it?
> One problem with the version stuff is that it relies on MySQL, and
> indeed on the ways table being a MyISAM table because it uses an
> auto increment column as the second component of an index to get a
> separate sequence for each id.
> Adding version to nodes and segments is possible - the big problem
> would be assigning versions to the existing records as there are
> places where there are multiple history records for an object with
> the same timestamp and hence no well defined ordering of them. It
> would also probably need a chunk of downtime while the conversion
> was being done.
That all makes sense. I was concerned I was missing something obvious. 
For now I'll go with the query per change approach and try to get 
something working. There's no point trying to get major changes into the 
database to support something that doesn't exist yet. If a replication 
mechanism does get off the ground then is the time to look at ways of 
improving efficiency.

Thanks for the help.


More information about the dev mailing list