On Nov 23, 2010, at 11:22 PM, Mike Orr wrote: > I can't read Ben's mind. I need to know what he expects it to contain. > If we're just talking a Session and Base object and initialize_sql(), > that's almost too little to justify a package.
So, my thought was that it'd have a DBSession in it, and the code necessary to setup the DBSession based on the settings, such that you could do: from pyramid_sqla import setup_dbsession # in the config stuff setup_dbsession(config) And that's it, the DB session settings will be read out of the settings with the assumption they start with 'sqlalchemy.'. If you want to change the default: setup_dbsession(config, prefix='sqlalchemy.read.') etc. As soon as that runs, the db engine will be setup. This command should be run at the very very top of the config ASAP, this way when you do add_handler, your handler can go ahead and import models, and even if its using reflection... the db is already setup. I believe this means we can finally have reflective models at module scope in the models.py or models/ package. So initially, pyramid_sqla will be a package that has: A) the db session setup, and a DBSession object ppl import, no more boiler-plate B) a pyramid_sqla project template C) Tutorial docs on using pyramid + sqlalchemy I say initially, because I think there's probably other useful things we can include here relevant specifically for using pyramid + SQLAlchemy that will let people make more assumptions about some basic SQLA things. For example, maybe the setup_dbsession command in the future might trigger an event "DBInitialized" that other event listeners might be waiting for to do something, etc. > Likewise, I can make a 'pyramid' template, but I'd rather have you and > Ben and me agree whether it's modules or packages, whether it will > include a starter view and welcome-page template, and what the > template language should be. These are central decisions that Pyramid > as a whole is committing to; we have to make sure all the main > developers are comfortable with the decision. Otherwise (A) developers > will be unhappy, or (B) we may end up reversing the decision and that > has cascading impacts on the docs/tutorials/tests as you've said. Chris said he can handle the default pyramid template, so that will be taken care of. I believe the final we'll go with for the single template included with pyramid will be: 1) It will use modules for views.py/models.py, with some instructions on splitting into package when needed 2) It will include a default 'welcome' template ending in .pt, .mako is also configured 3) No other decisions about ORM/etc. will be made This is just for the template in pyramid. For consistency, all templates for pyramid should have either a views.py or views/ package, and a models.py or models/ package as appropriate. > Changes happen, but Ben usually comes up with excellent structures > that fit a lot of use cases and don't need much changing later. He > just takes a while to explain enough of his ideas to make spec from. For pyramid_sqla, if the tutorial you're writing is going to have large models where the size of models.py would likely pass 1k of code, the pyramid_sqla template should probably make models a package instead of a models.py. Cheers, Ben -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-de...@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
