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. -- Stuart Bishop <[email protected]> http://www.stuartbishop.net/ _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
