On Fri, Aug 27, 2010 at 2:37 PM, Stuart Bishop <[email protected]> wrote: > On Fri, Aug 27, 2010 at 2:39 AM, Robert Collins > <[email protected]> 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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
