On Dec 19, 2007, at 1:11 PM, Mike Orr wrote:
That looks cool except I'd like the template to have init_model(engine) rather than the pylons.g.engine.
I'm adding it right now with pylons.g.engine, we can take a look then and review.
That makes it easier to import the model anytime, and to use it without depending on Pylons/config/g. "Making a Pylons Blog" shows the structure. http://wiki.pylonshq.com/display/pylonscookbook/Making+a+Pylons+Blog The only undocumented parts are: - For multiple databases, pass multiple args to init_model, and use sessionmaker(binds=) if necessary. - If reflecting, put the table defs inside init_model. - How to split large models into several modules. (Put the metadata in a separate module, and perhaps the table definitions with it. Put Session in __init__, and have init_model copy Session into the ORM other modules for convenience. This breaks if you reload the ORM module in "paster shell": you have to copy the Session again manually or re-run init_model. But it does avoid circular imports. There may be a better way, but that need not affect the application template, which is just to get you started with a small model.)
I was going to go with making a meta.py module in models/ that has metadata and Session. This is what I've been using in my projects as well to avoid circular import issues with models broken into multiple modules and its worked fine.
With regards to making things easier to plug into with other 'apps', someone working for Mark Ramm has been exploring this too and his solution was to create a Models object that all the other modules 'register' their SA table and class objects with. This way you could even tell a project that XXX app will be used, and I could see having it scan the other packages entry points for a list of models that it should then load up... etc.
Anyways, first things first, a working SQLAlchemy template that mirrows SQLAlchemy in a Hurry, which I should have in pylons-dev shortly.
Cheers, Ben
smime.p7s
Description: S/MIME cryptographic signature
