On Wed, Feb 11, 2009 at 1:55 PM, Iván Sánchez Ortega <[email protected]> wrote: > For changeset timeouts: triggers, triggers, triggers. Or just initialize the > closing time of a changeset to a date in the future.
the closing time trick is how the rails code works. would you also add triggers for changeset bbox updates and element count? >> also, it becomes a pain for the client to distinguish between a mysql >> error because of an invalid foreign key reference, a mysql error >> because of a server code bug and a mysql error because the db server >> died or the network went down. > > Can't Rails check the error number returned by MySQL? s/the client/rails/ - its a pain for someone. then you'd just complain that the rails code was too slow because it was constantly checking error codes! seriously, if you have some suggestions for improvements in the server code or DB design post-0.6 then i'm sure we'll be having many discussions and hack days which you're more than welcome to participate in. at the time the API 0.6 design was sketched (out a whole year ago) speed was not the top priority - but you can make your voice heard for 0.7 ;-) right now we're not going to make any major changes to the API or server code because the client authors and DB admins asked if we could have a period of code and DB schema stability before the release, which is less than 6 weeks away. cheers, matt _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
