launchpad-dev team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

On Fri, Aug 27, 2010 at 2:37 PM, Stuart Bishop
<stuart.bishop@xxxxxxxxxxxxx> wrote:
> 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.

I think code generation that outputs .py files could be pretty nice.

We can introspect using text editor, and have bzr told not to let
those files be commited. Or something.

-Rob