Voltron asked for an interim SQLAlchemy configuration until the
proposed SAContext module actually exists. His is a one-engine
PostgreSQL situation with straightforward relationships.
=== models/init.py
from pylons.database import session_context as ctx
engine = ctx.current.bind_to
meta = BoundMetaData(engine)
table1 = Table("Table1", meta, ...)
class Class1(object):
pass
mapper = Class1, table1)
def high_level_access_function():
return ctx.current.query(Class1).filter(...).order_by(...).list()
def another_access_function():
"""Returns the Query so the caller can call .list(), .count(), etc
as it wishes from the same query.
"""
return ctx.current.query(Class1).filter(...).order_by(...)
===
Three things to note here:
(1) Pylons applications do not need DynamicMetaData; using it adds
compilcation to no advantage. BoundMetaData works for both autoloaded
tables and conventionally-defined tables. Both BoundMetaData and the
engine are thread safe. ("SQLAlchemy for People in a Hurry" is wrong
in this regard.)
(2) This configuration honors 'sqlalchemy.dburi' and 'sqlalchemy.echo'
in the config file, but there is no way to pass other engine options.
If you need to pass other options like "pool_recycle" for MySQL, it's
easiest right now to copy pylons.database to myapp.lib.database and
hardcode the desired options into the create_engine() function. Then
use your module instead of pylons.database.
(3) Proper SQLAlchemy as articulated by Michael Bayer would be to
define the engine first, then a BoundMetaData, then a session_context
with no special arguments (i.e,. no custom make_session). Binding a
session to an engine would not be necessary because all tables are
permanently bound to the engine via BoundMetaData. However,
pylons.database currently takes the opposite approach, predefining a
session_context so you have to use session_context.current.bind_to to
access the engine, or create an identical engine with create_engine().
Yet on the other hand, pylons.database conveniently parses the dburi
for you, and it handles the app_scope() apparently needed for
session_context, so it's easier to modify a copy of pylons.database
than to write everything from scratch.
--
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
-~----------~----~----~----~------~----~------~--~---