I recommend the status quo. My reusable pyramid application will not need to
import pyramid_sqla. It will:
- have its own declarative base
- require the user to call ponzi_auth.configure_database(engine)
- not use database reflection, and so will not need a configured engine
before imp
On Wed, Nov 24, 2010 at 2:15 PM, Ben Bangert wrote:
> On Nov 24, 2010, at 1:49 PM, Mike Orr wrote:
>
>> So do we need multiple sessions? I'm not sure we've defined the use
>> cases clearly enough, which runs the risk that we'll make an API that
>> won't be adequate anyway. So I'm inclined to use a
On Nov 24, 2010, at 1:49 PM, Mike Orr wrote:
> So do we need multiple sessions? I'm not sure we've defined the use
> cases clearly enough, which runs the risk that we'll make an API that
> won't be adequate anyway. So I'm inclined to use a single session. We
> can always add a multisession object
On Wed, Nov 24, 2010 at 11:25 AM, Ben Bangert wrote:
. I'm sure we can work out something somewhat flexible for changing
engine bindings to a session on the fly though, like:
>
> from pyramid_sqla import set_session_bind
>
> set_session_bind(session='read_only', engine='db2')
>
> And it'll switch
On Nov 24, 2010, at 10:58 AM, Mike Orr wrote:
> There are a few limitations with putting the dbsession and initialize
> function in a package:
>
> 1) The model is no longer autonomous. A Pylons model can be imported
> and used on its own, even if the rest of the application or Pylons has
> some
There are a few limitations with putting the dbsession and initialize
function in a package:
1) The model is no longer autonomous. A Pylons model can be imported
and used on its own, even if the rest of the application or Pylons has
some error that makes it unusable. A db utility can simply creat
On Nov 24, 2010, at 9:53 AM, Daniel Holth wrote:
> I am also interested in having unrelated packages participate in the
> SQLAlchemy session but unfortunately have not had the opportunity to write
> and release those packages. A couple of SQLAlchemy notes:
Yea, that is one of the things having
I am also interested in having unrelated packages participate in the
SQLAlchemy session but unfortunately have not had the opportunity to write
and release those packages. A couple of SQLAlchemy notes:
It is not necessary for every mapped class to inherit from the same
declarative base class. For
On Nov 23, 2010, at 11:22 PM, Mike Orr wrote:
> I can't read Ben's mind. I need to know what he expects it to contain.
> If we're just talking a Session and Base object and initialize_sql(),
> that's almost too little to justify a package.
So, my thought was that it'd have a DBSession in it, and
Thanks for this. I'll refer to it once it comes around on the guitar to
unscrew the views chapter.
- C
On Tue, 2010-11-23 at 22:41 -0800, Mike Orr wrote:
> On Tue, Nov 23, 2010 at 8:21 PM, Mike Orr wrote:
> > On Tue, Nov 23, 2010 at 8:00 PM, Chris McDonough wrote:
> >> On Tue, 2010-11-23 at 19
On Nov 23, 2010, at 7:50 PM, Chris McDonough wrote:
> I'd suggest instead:
>
> newproj/
>__init__.py
>views.py
>tests.py
>models.py
>templates/
> mytemplate.pt
>static/
>
>
> Such a template might be named "pyramid_diy". "pyramid_diy" would be a
> template u
11 matches
Mail list logo
