On 27/12/2011 16:05, Michael Bayer wrote:
The purpose of SQLAHelper is to solve the most common problem, which
is sharing a single Base and Session across multiple modules,
including those written by third parties who don't know about your
application.
What's the use case for a Base being shared to a third party module that
doesn't know about your application?
I've hit the situation where I've needed to share a base across multiple
python packages, only some of which might be used in a particular project.
A Base might have any number of behaviors on it, like certain columns, naming
conventions, __mapper_args__(), attribute names, that can't be anticipated by a
third party library.
Yep, that's why I built the registry of bases the way I did in mortar_rdb:
http://packages.python.org/mortar_rdb/api.html#mortar_rdb.declarative_base
The only reason I can think of, is the "well you can't link via ForeignKey or
relationship() with a separate base". But this is not really true, for a variety of
reasons.
I still think it'd be great if the registry tied to the base was
actually in the metadata object. One metadata object instead of two, but
I have a feeling we've had this conversation before ;-)
Why not standardize SQLAHelper on a "one by default, many if desired" model ?
Also as an alternative to the getter/setter style, why not just:
helper = SQLAHelper()
# default objects: "base", "session", "engine":
default_base = helper.base
default_session = helper.session
helper.engine = create_engine(...)
# namespaces for each, "default" points to the "default":
helper.bases.default is helper.base
helper.sessions.default is helper.session
helper.engines.default is helper.engine
I'm fairly indifferent to the above, I prefer registries myself....
# alternates to the "default":
helper.bases.generic_base = Base()
....but this doesn't solve my use case of having a base shared across
multiple packages, only some of which may be installed, and some of
which may be third party.
I think multiple sessions should be supported. My current app uses two simultaneously as many classes are represented
in two different databases at the same time - one is the "live" database the other is "historical".
An application that switches between "master" and "slave" databases at the session level needs
to do this also.
Yep: http://packages.python.org/mortar_rdb/api.html#mortar_rdb.getSession
...just register each ression with a different name.
cheers,
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
--
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.
