← Back to team overview

launchpad-dev team mailing list archive

Re: Some launchpad data model thoughts

 

On Fri, 27 Aug 2010 07:39:28 +1200, Robert Collins <robert.collins@xxxxxxxxxxxxx> wrote:

> I see this as a limitation of Storm, our ORM : other ORM's (both in
> and out of the python world) have an explicit, decoupled, mapping
> layer. Working with Storm though, the usual idiom (at least in
> Launchpad - I need to spend a couple of days with Jamu in the
> Landscape code looking for inspiration) is to be expressing things at
> the SQL layer.

Where my imagination on how this could work gives out is the issue that
we express some really very core logic as SQL.  For some reason
findBuildCandidate springs to mind, but there are countless other
examples.  I've worked on one of the few verified fakes we have in the
codebase -- lp.codehosting.inmemory -- and it's frankly a pain,
duplicating much logic from the database implementation (and missing
bits, like full access control).  Clearly this fake is at the wrong
level, but I don't really understand what the right level is.

Tests that use lp.codehosting.inmemory do go very fast though.

Cheers,
mwh



References