[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

-- 
Tom Hughes (tom at compton.nu)
http://www.compton.nu/




More information about the dev mailing list