On 6/27/07, Michael Bayer [EMAIL PROTECTED] wrote:
Of course the engine must be initialized before any tables can be
defined or any work done.
since ive seen people get the wrong idea about this, let me
reiterate: *you can define all your tables and mappers with no
database connection
On 6/27/07, Uwe C. Schroeder [EMAIL PROTECTED] wrote:
if you
really want COMMIT for every SELECT, i'd favor it being enabled via an
option passed to create_engine().
Not every select, every transaction that didn't roll back.
I just think the default of rollback on every transaction is
On Wednesday 27 June 2007, Mike Orr wrote:
On 6/27/07, Uwe C. Schroeder [EMAIL PROTECTED] wrote:
if you
really want COMMIT for every SELECT, i'd favor it being enabled via an
option passed to create_engine().
Not every select, every transaction that didn't roll back.
I just think
Previously Michael Bayer wrote:
On Jun 27, 6:42 pm, Ian Bicking [EMAIL PROTECTED] wrote:
The way I see this working is something like (vaguely):
def transaction_middleware(app):
def wrapper(environ, start_response):
manager = TransactionManager()
On Thursday 28 June 2007, Mike Orr wrote:
And this. If you have a 50-column table, by gosh SQLAlchemy is going
to select all 50 fields in full `TableName`.columnName AS columnName
notation, which makes the query hard to read in the log.
M - a 50 column table? My old CS teacher will
Michael Bayer wrote:
im not exactly sure why Jonathan thinks that the url forces one
to define my connection up front. if youre saying, i want to
distribute the application without an .ini file thats fine...but when
the thing is actually *used*, there will be an .ini file or other
I'm currently making an attempt to wrap a Turbogears app in a simple
authentication layer using AuthKit, but I am running into a problem
that's got me stumped. Here's a snippet from my start-project.py:
def valid(environ, username, password):
return (username=='ryan' and password=='secret')
Michael Bayer wrote:
just to clarify, however this works, it should be *really easy* for
individual controller methods to be marked as transactional or not.
I have written decorators like these already, in the style of:
class MyController(...):
def index_page(self):
.
On Jun 28, 1:40 am, Uwe C. Schroeder [EMAIL PROTECTED] wrote:
On Wednesday 27 June 2007, Michael Bayer wrote:
this issue can be worked around by using explicit transactions.
actually no, it can't. Maybe I don't get it right, but the only way for me to
get a commit was actually to modify
On Jun 28, 2:09 am, Mike Orr [EMAIL PROTECTED] wrote:
I would probably want this optional URI in a subclass rather than in
SAContext itself. The reason 'uri' is a required argument is to
guarantee that the default engine is initialized at all times. When
we designed SAContext we (Mike
On Jun 27, 5:56 pm, Ian Bicking [EMAIL PROTECTED] wrote:
* 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
On Jun 28, 2007, at 9:58 AM, Jonathan LaCour wrote:
Michael Bayer wrote:
just to clarify, however this works, it should be *really easy* for
individual controller methods to be marked as transactional or not.
I have written decorators like these already, in the style of:
class
Michael Bayer wrote:
the way this idea works is that if some wrapping component knows
it needs a transaction, it opens one. then the controller method
participates in that transaction, regardless of whether or not its
marked as @transactional.
Of course, that makes complete sense. As long
Michael Bayer wrote:
On Jun 27, 6:42 pm, Ian Bicking [EMAIL PROTECTED] wrote:
The way I see this working is something like (vaguely):
def transaction_middleware(app):
def wrapper(environ, start_response):
manager = TransactionManager()
environ['transaction.manager']
On Jun 28, 11:46 am, Ian Bicking [EMAIL PROTECTED] wrote:
So as middleware I think it should be fine. If you want to catch a
problem with the commit and handle it gracefully, I think you can just
do your own commit in your code (and the middleware commit will just
commit what little
On Jun 28, 2007, at 12:42 AM, Ian Bicking wrote:
Jonathan LaCour 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
Alberto Valverde wrote:
I'd like to add here that I've got use-cases for the transaction
boundary and session initialization being closer to the server than
what the __before__ and __after__ hooks provide.
For example, the authentication function I feed to AuthKit which uses
a DB
Alberto Valverde wrote:
On Jun 28, 2007, at 12:42 AM, Ian Bicking wrote:
Jonathan LaCour 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
On Jun 28, 2007, at 7:33 PM, Jonathan LaCour wrote:
Alberto Valverde wrote:
I'd like to add here that I've got use-cases for the transaction
boundary and session initialization being closer to the server than
what the __before__ and __after__ hooks provide.
For example, the
On Jun 28, 2007, at 7:45 PM, Ian Bicking wrote:
Alberto Valverde wrote:
On Jun 28, 2007, at 12:42 AM, Ian Bicking wrote:
Jonathan LaCour wrote:
Ian Bicking wrote:
Personally I'd like to see something a bit different:
* Way for a library to get the transaction manager.
* Interface
On Thursday 28 June 2007, Michael Bayer wrote:
On Jun 28, 1:40 am, Uwe C. Schroeder [EMAIL PROTECTED] wrote:
On Wednesday 27 June 2007, Michael Bayer wrote:
this issue can be worked around by using explicit transactions.
actually no, it can't. Maybe I don't get it right, but the only
On 6/28/07, Jonathan LaCour [EMAIL PROTECTED] wrote:
3. Either some middleware or just a few lines inside the
BaseController
of the TurboGears template that starts a transaction on every
request and puts it into the transaction manager.
And, in my opinion, items #1 and #2
On Jun 28, 2007, at 8:52 PM, Mike Orr wrote:
On 6/28/07, Jonathan LaCour [EMAIL PROTECTED] wrote:
3. Either some middleware or just a few lines inside the
BaseController
of the TurboGears template that starts a transaction on every
request and puts it into the
On 6/28/07, Alberto Valverde [EMAIL PROTECTED] wrote:
On Jun 28, 2007, at 8:52 PM, Mike Orr wrote:
On 6/28/07, Jonathan LaCour [EMAIL PROTECTED] wrote:
3. Either some middleware or just a few lines inside the
BaseController
of the TurboGears template that starts a
Mike Orr wrote:
... and available to non-TG Pylons applications. The @transactional
decorator sounds like a good idea, possibly with a False flag if the
default is transactional.
Agreed.
This is a good point to ask, how will the TG template differ from
the standard Pylons template? Will
On 6/28/07, Jonathan LaCour [EMAIL PROTECTED] wrote:
The TurboGears template, as of right now, is basically the same as
a Pylons template, only it includes a default route to a special
WSGIController subclass called TurboGearsController that implements
all sorts of nice things, like
Mike Orr wrote:
So if i want to use this for all URLs under a certain prefix, I would
direct the route to my subclass of TurboGearsController, using action
route (always?).
Well, thats the idea. It needs lots of love and testing, though.
Line 66 (object_dispatch) returns my TG action
On 6/28/07, Jonathan LaCour [EMAIL PROTECTED] wrote:
Mike Orr wrote:
So if i want to use this for all URLs under a certain prefix, I would
direct the route to my subclass of TurboGearsController, using action
route (always?).
Well, thats the idea. It needs lots of love and testing,
On Jun 28, 2:32 pm, Uwe C. Schroeder [EMAIL PROTECTED] wrote:
If I could figure out how, I probably would. The code from the docs doesn't
work, because TG does something around that. I guess one of the major
drawbacks of TG is it's documentation (or lack thereof) when it comes to
using SA
On Jun 28, 2:01 pm, Alberto Valverde [EMAIL PROTECTED] wrote:
One problem I see is that this might cause trouble in cases like this:
Request
|
V
db transaction middleware - creates session A
|
V
authentication middleware - authenticates user and keeps ref to User
drawbacks of TG is it's documentation (or lack thereof) when it comes to
using SA together with it.
I actually asked Michael Bayer a couple of dumb questions as result of not
knowing what the controller did in a SQLAlchemy turbogears project. I am
glad I wasn't the only one who was
For me TG on Pylons would be a set of similar packages-components
that make thinks easier and quicker
- wrappers for various backends (tg-user for authkit and others)
- set of helpers (toscawidgets, webhelpers)
--~--~-~--~~~---~--~~
You received this message
Funny you mention Twisted. May app is actually Twisted based - and yes, I
agree. I had some good (and some bad) experiences with Glyph emailing back
and forth to get things resolved :-)
On Thursday 28 June 2007, Noah Gift wrote:
drawbacks of TG is it's documentation (or lack thereof) when
On 6/28/07, Noah Gift [EMAIL PROTECTED] wrote:
I am pretty sure Turbogears riding on Pylons will be on a vengeance to
document things correctly and not just the API, but usage scenarios for
everything.
Joining forces will make a big difference. TG and Pylons combined
probably account for
34 matches
Mail list logo
