Tnx for the confirmation. I guess 0.6 API aims to fix that with atomic uploads, but Potlatch will remain using its own "API", right? Is it now (version 0.10) preventing this somehow?
so the events went something like: - user adjusts the way somehow [common operation] - potlatch decides to delete old way and create a new one for some reason [stupid (breaking history), but legal] - potlatch deletes old way and all the nodes it can (those that aren't used by other ways where other rivers join the riverbank) [stupid, but ok] - potlatch creates a new way, consisting of old (now mostly deleted) nodes [illegal] Not really sure this has anything to do with missing transactions, more likely some bad logic. Foreign keys in the db on current_ways -> current_nodes could prevent that, but AFAIK they aren't used for performance reasons. But why is potlatch today STILL showing the riverbank as it would be there, but in fact it isn't? If this accident would be visible to the user then he could do something about it (re-draw it in worst case) immediately. Stefan ---------- Forwarded message ---------- From: Richard Fairhurst <[EMAIL PROTECTED]> Date: Tue, Jul 22, 2008 at 9:52 AM Subject: Re: [OSM-dev] Potlatch causing DB inconsistency? To: [email protected] Stefan Baebler wrote: > Any ideas what's going on? I think it's reasonably well attested that, without transactions, this sort of thing is going to happen once in a while. As posted the other day, Potlatch's database access code has been rewritten almost beyond recognition for 0.10 (see http://tinyurl.com/5996mn) so there's not a whole lot of point filing bugs against 0.9c; let me know if you see anything like this happen with 0.10, of course. cheers Richard _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
