On Dec 26, 2011, at 11:58 PM, Mike Orr 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?  This sounds like a bad idea.   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.

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.

That said I have a feeling some libraries are already doing this but I wish we 
could work out a better way than using inheritance as a third party plugin 
point - one of Ben's key rationales for dumping Pylons altogether is that it 
was built on this model for extensibility.

> But when you start getting multiple databases in the
> application, it may get beyond what the shared Base can provide. In
> that case, you can decide whether one database is general-purpose,
> used by several modules and third-party libraries, while another
> database is single-purpose, used only by one module. Then there's a
> clear answer: use SQLAHelper's Base for the shared database, and your
> own Base for the single-purpose database. For instance, the second
> database may be specifically for site statistics, searching, an
> external database you're consulting, etc. These would all be
> single-purpose databases, which wouldn't have to be shared.

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

# alternates to the "default":

helper.bases.generic_base = Base()
helper.sessions.alternate_session = scoped_session(...)
helper.engines.alt1 = create_engine(...)


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.


-- 
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.

Reply via email to