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 including autocommit, 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 at http://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
-~----------~----~----~----~------~----~------~--~---
