[OSM-dev] [OSM-talk] Trouble in Rangoon

Marcus Wolschon marcus at wolschon.biz
Thu Feb 28 13:25:31 GMT 2008

Hash: SHA1

Frederik Ramm schrieb:
| I agree that this would probably be the fastest way but I have a
| personal dislike against stored procedures ;-) they're so out-of-
| sight if you know what I mean.

Yes, I can see that.
Implementing it in application-code is
much cleaner, easier to debug and independent
of the database used.
Is there a way to setup a test-system localy
and do realistic load-tests to see if any particular
implementation is fast enough for the main-server?
Are we able to generate such test-cases?

| True. However deletions are only one way of wreaking havoc. Using
| JOSM it is easy to move the whole of London 200m to the West, or make
| it switch places with Paris. (Well not *easy* but not hard either!)

Very True.

|> In the end we really need something like
|> the history-tab in wikipedia without breaking
|> referential integrity uppon restores. Once
|> accidents and vandalism becomes more common
|> there is not much of a way around that.
| Yes, absolutely.
| I have written my two cents on the subject here:
| http://wiki.openstreetmap.org/index.php/Changesets_and_Reverts
| I'd invite everybody to discuss (perhaps better on the list than on
| the Wiki, but each to his liking).

I really like the replacement of the "created_by"-tag here.
It reflects reality in that an entity can and is often
inserted with editor 1 and edited with editors 2 and 3.

Why to you suppose the editor give a changeset-api?
What about threating every upload as a new changeset
and make it transparent to the client?
This way all clients still work and they can implement
support for "get_history", "revert_changeset" and "get_changeset"
at any later time.

Can changesets be implemented without transactions and
what does it cost to have transactions in the database?

For a revert I strungly suggest the revert be a conventional
changeset with delete+create+modify -operations. I also strongly
suggest not to disallow dirty reverts completely, because then
moving a single node after all of london is "misplaced" can break
the revert of that edit.

Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the dev mailing list