On Fri, 27 Aug 2010 07:39:28 +1200, Robert Collins <[email protected]> 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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
