I removed the "model." prefix in the Data Queries section. Could we please keep it that way? I put this at the top of the section:
"Important: this section assumes you're putting the code in a high-level model function. If you're putting it directly into a controller method, you'll have to put a model. prefix in front of every object defined in the model, or import the objects individually. Also note that the Session object here (capital s) is not the same as the Beaker session object (lowercase s) in controllers." As for examples that are clearly in a controller (e.g., model.Session.remove()), I kept the "model." prefix because that's the Pylons default, and it's what I prefer in my own applications. It also avoids the Session vs session collision. I removed one "model." prefix on the scoped_session line. That's inside the model itself! Regarding Session, it's unfortunate SQLAlchemy chose that word. Keeping Session keeps us consistent with the SQLAlchemy docs. "session" may cause even greater confusion. We can call the variable anything we want, would "sasession" or "sasess" be better? "sa_session" may be a bit cumbersome. Technically, Session is a class created by scoped_session, and its class methods shadow the session methods and delegate to the implicit current session. Yes, it's kind of like a StackedObjectProxy. So, shall we change the name? However, this classmethod thing has hit a collision with model.Session.configure(bind=) in the "Multiple Engines" chapter. MikeB says the example does not do what it says: it affects only future sessions, not the current one. We're discussing how to handle this on the pylons-devel list. It's easy to work around this; but it's harder to explain it to newbies without introducing additional syntax. We may have to do model.Session().configure(bind=), which is inconsistent with the other class methods. Mike has suggested a lambda but I'm not sure it will work. I'm wondering if SQLAlchemy needs to rethink its .configure method or add another method. So this is up in the air. Regarding commit, I'm -1 on doing it by default. But is that what TurboGears normally does? Does it work well there? We could put a commented commit line in the base controller, and explain in the text the consequences of uncommenting it. -- Mike Orr <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
