launchpad-dev team mailing list archive

[Stuart Bishop <stuart.bishop@xxxxxxxxxxxxx>]

On Fri, Aug 27, 2010 at 2:39 AM, Robert Collins
<robert.collins@xxxxxxxxxxxxx> wrote:

> To me, finishing the SQLObject migration will remove a bunch of nasty
> surprises and give us a saner base to go forward with experiments on
> mapping. To be clear: I'm ok with folk experimenting with different
> sorts of mapping; (I don't think a parallel class structure is
> necessarily all that great - in python we could be more dynamic than
> that). However, I think it will be very hard to do well, safely and
> incrementally until SQLObjectResultSet specifically, is purged.

One thing I've always wanted to try was to generate the Python ORM
database class and an Interface from the database schema. It contains
all the information we need. This will remove most of the boilerplate,
leaving things much clearer. You could subclass these, adding our
business and ending up with pretty much what we already have in
.model. Or just use them in the raw from utilities, adapt them to
domain specific classes etc. But I certainly think it would encourage
domain specific classes embedding just the domain specific business
logic rather than the current approach of dumping everything in the
one-true-database-class.

This would go into Storm upstream I think (PostgreSQL only - someone
else can work out how to introspect the other database flavors). I
always vacillate between code generation, so you can introspect using
your text editor, or on the fly, requiring you to introspect using a
debugger or generated documentation.

-- 
Stuart Bishop <stuart@xxxxxxxxxxxxxxxx>
http://www.stuartbishop.net/