The following location needs to be updated to reflect the transactional -> autocommit change too:
http://docs.pylonshq.com/models.html#main-model-module It still quotes/recommends a code example containing 'transactional=true'. And paster gives a deprecation warning for this; one would hope (mildly) that such warnings issued by the server would be in sync with the docs. Thanks! On Sep 16, 7:59 am, Michael Bayer <[EMAIL PROTECTED]> wrote: > On Sep 15, 4:21 pm, "Mike Orr" <[EMAIL PROTECTED]> wrote: > > > It sounds like both you and MikeB are recommending this. Is the > > SQLAlchemy manual also going to recommend it? We set up the Pylons > > 0.9.6 / SA 0.4 configuration to the lowest level possible because we'd > > had too many problems defaulting to extensions that were too magical > > and/or later deprecated. > > declarative was introduced in 0.4 and remains pretty much the same in > 0.5 though it works better in 0.5. Ben's concern with declarative is > the use case of the 800-table model where you don't want everything in > one big file, though I don't think there's much difference in how you > deal with that whether or not declarative is in use (in both cases, > some single module needs to import the full extent of mappers and > tables, whether or not the mappers/tables/classes are broken up, or > stated in single units). > > > I've been waiting for SA 0.5 to be released before changing the > > tutorial or my own apps, to avoid having to change things multiple > > times as SA evolves. I guess now 0.5 is in RC status it's close > > enough. > > the point of RC status was to get people to stop worrying about API > changes, but to leave room for any lurking issues that would only > become apparent with widespread usage. > > > There have been several changes in SA 0.5 includingautocommit, new > > ways to create the session, Declarative, etc. These have made me > > unsure what to put into the new model. > > There's really no change to how to create the session. sessionmaker()/ > scoped_session() are still used in the same way. We just changed the > name of the "transactional" keyword argument to "autocommit". > "transactional" is still accepted with a warning. So its not really > different in any significant way. > > > Another issue we haven't resolved is sharing the Session/engine with > > middleware. What if anything should we do about that? Currently the > > middleware is on the hook for clearing the session when it finishes, > > if the app has already been called. And of course, if the middleware > > writes something before calling the app, the app will commit or roll > > it back. I suppose sharing engines doesn't matter. Should the > > middleware just make its own session? Is it OK to have two sessions > > open simultaneously in the same thread? > > Middleware can share an engine without issue. As far as a Session, I > think its better that middleware have its own session so that there is > no implicit interaction in the transactional space between middleware > and application....nobody is going to want to be surprised by that. > However, this may depend heavily on what kind of middleware we're > talking about. I would think its up to middleware authors to decide > which approach is more appropriate. > > > Note that upgrading the default model will mean it's no longer > > compatible with SA 0.4. How much is this a concern? > > the compatibility changes would be very slight, I'd imagine that > theres an option between SQLA 0.4/0.5 for the time being. > > > Pylons has StackedObjectProxies for config, app_globals, request, > > response, and tmpl_context. These are supposedly better than > > threadlocals in case multiple instances of the same Pylons application > > (or different Pylons applications?) are running in the same process. > > For two different applications running in one process, each has a > distinct Session class configured in their model package so no stacked > proxy is needed. For the two instances of the same app running in a > process, you'd need a stacked object proxy only because I'd assume > both instances talk to different engines, and we generally like to > have one Session class associated with an engine. > Both use cases are in my experience totally nonexistent - I can't > imagine the point of running two applications in one Python > interpreter, taking on the burden of keeping both namespaces away from > each other, as well as any other weird side effects, when there are so > many easy ways to run multiple Python interpreters. > > for reference my current base.py looks like: > > class BaseController(WSGIController): > > def __call__(self, environ, start_response): > try: > return WSGIController.__call__(self, environ, > start_response) > except: > meta.Session.rollback() > raise > finally: > meta.Session.remove() > > init_model: > > def init_model(engine): > """Call me before using any of the tables or classes in the > model""" > > if not meta.Session: > sm = orm.sessionmaker(autoflush=True,autocommit=False, > expire_on_commit=False, bind=engine, extension=<some extensions I'm > using>) > > meta.engine = engine > meta.Session = orm.scoped_session(sm) > > I also *very* occasionally use a "without_autoflush" decorator, when > I'm populating an object to be flushed with data that comes from > queries: > > @decorator > def without_autoflush(fn, self, *args, **kwargs): > """Disable the Session autoflush feature > for the duration of the decorated method. > > """ > meta.Session().autoflush=False > try: > return fn(self, *args, **kwargs) > finally: > meta.Session().autoflush=True > > a typical transactional controller method (using the validate > decorator described athttp://techspot.zzzeek.org/?p=28): > > @validate("some_form", SomeForm(), input_controller=edit) > def save(self, id): > id = int(id) > object = Session.query(Class).get(id) > if not object: > abort(404) > self._populate_object(self.form_result, object) > Session.commit() > h.flash_success("item saved") > redirect_to(controller="mycontroller", action="view", id=id) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
