On 6/27/07, Jonathan LaCour <[EMAIL PROTECTED]> wrote:
>
>
> Ian Bicking wrote:
>
> > Personally I'd like to see something a bit different:
> >
> > * Way for a library to get "the" transaction manager.
> > * Interface for that transaction manager, maybe copied from Zope.
> > * Single convention for how to specify a database connection (ideally
> >   string-based).
> > * Probably a way to get "the" configuration, so you can lazily get
> >   a connection based on the configured connection.
> >
> > The frameworks would setup the transaction manager and configuration,
> > and database frameworks would basically consume this information.
>
> This would be pretty much ideal, and would satisfy my use cases very
> well.  It would also allow framework authors to build in support for any
> ORM / database layer in an agnostic way, sort of like the Buffet API
> does for templating systems.
>
> Then, we could also create a simple WSGI middleware for Pylons that
> gives it TurboGears-like automatic transaction start/commit/rollback
> on a per request basis.  Only, we could make it configurable so that
> it didn't happen on read-only operations.  All of this would be ORM /
> database layer agnostic, which would be very nice indeed.
>
> The big issue for me with SAContext right now is that it uses a
> BoundMetaData and expects you to know your dburi "up-front" as it
> were.  I don't like having my model tied to my configuration system.
> I'd rather have my model fetch its configuration from some third party
> source, such as this new package we are discussing, so that I can
> create desktop applications, command line utilities, etc. that share my
> pylons application's model, without having to ship pylons or a pylons
> configuration file.  The last thing that Ian requests here would let me
> do that to a certain extent:
>
>      from db_buffet_api import config
>      from sacontext import SAContext
>
>      sac = SAContext(dburi=config.dburi)
>
> So, I am a big +1 on such a beast.


I agree on being able to control the transactions!

My two cents to add are that it would be great to have control over
transactions being turned on or off on a per controller basis and to have a
way to allow Turbogears style validation that is database specific.  For
example...check to make sure this isn't already in the database for
me...(might be too crazy to implement though...)







--
> Jonathan LaCour
> http://cleverdevil.org
>
>
> >
>


-- 
http://www.blog.noahgift.com

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