[OSM-dev] The future of Potlatch

Tom Hughes tom at compton.nu
Fri May 2 12:27:38 BST 2008

In message <20080502111655.GB12755 at metacarta.com>
        Christopher Schmidt <crschmidt at metacarta.com> wrote:

> On Fri, May 02, 2008 at 08:35:06AM +0100, Tom Hughes wrote:
>> To summarise I think we both want the same thing, but you perhaps
>> think somebody should just sit down and bang an AMF version of the
>> current XML API and I'm happy with trying to incrementally move
>> towards that position?
> Well, I don't think that's how I would put it. I think you were slightly
> oversimplifying when you just said "It's a few lines of Rails object
> code." Some of the request methods in Potlatch are at least a bit more
> complex than that. getway_old, for example, is slightly more complex
> than that, as is putway.

Neither of those methods has been converted to using rails yet - they
are both still using raw SQL to do the work.

Methods which have been converted are things like whichways and getpoi.

> I won't pretend that I know nearly as much about the rails code as you
> do, but it seems like some of these would be better abstracted out. If
> that were the case -- that is, that all the Rails code on the site used
> the same underlying methods to talk to the database, given a 'fixed'
> API, and amf_controller was just about encoding the returned data into
> AMF -- then I thiink it would be possible to change the underlying slow
> methods into SQL (after proper profiling), because the main reason not
> to is 'maintaining two different codebases sucks', rather than 'no one
> likes SQL over rails'.

If I thought Steve would let me get away with doing raw SQL instead
of using the rails object model I might have done so long ago ;-)

Doing so would bypass all the integrity checks though, which is
bad - that's a side effect of having the integrity checks in the
wrong place (the rails object model rather than the database).


Tom Hughes (tom at compton.nu)

More information about the dev mailing list