On 6/29/07, Mike Orr [EMAIL PROTECTED] wrote:
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
On 6/29/07, Mike Orr [EMAIL PROTECTED] wrote:
On 6/29/07, Noah Gift [EMAIL PROTECTED] wrote:
Yes, this is really exciting stuff. I vote we capitalize on the energy
will
it is hot and start making subprojects and delegating things. One
excellent
strategy is to use community user groups
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
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
And in breaking news ...
Jonathan LaCour writing at http://cleverdevil.org/ says :
This past weekend, Mark Ramm and I held a sprint to experiment on
implementing a TurboGears like API on top of the excellent Pylons web
framework. The sprint was hugely successful, and as a result,
TurboGears 2.0
I couldn't be happier with this news. I've been using TurboGears for
almost a year now, and had been frustrated with the stagnation in
development and the myriad of Python web frameworks. I'm glad to see
two of the top contenders combining, rather than duplicating, their
efforts.
Keep up the
I couldn't be happier with this news. I've been using TurboGears for
almost a year now, and had been frustrated with the stagnation in
development and the myriad of Python web frameworks. I'm glad to see
two of the top contenders combining, rather than duplicating, their
efforts.
Pylons
[checking my watch] It's not April 1st so this must be true.
Reminds me of ZDjangoGears and the joke that ultimately became Parrot.
This is great news for Python web interpoerability! Pylons users
will benefit from having access to a TG-style dispatcher and
decorators for validation, JSON,
It's proven trivial to drop SAContext into
an existing Pylons application (one variable definition and two
search-and-replaces) so I expect the same will be true for TG
applications.
Yea, Jonathan has stuff to talk to you about. I think SAContext
could be pretty easily modified to meet his
Mark Ramm wrote:
I'd like there to be an entry point for database engines (SA, SO,
DejaVu, or whatever) that offer a very minimal set of functions in a
database agnostic way.
* connect
* start_transaction
* end_transaction
* rollback
Personally I'd like to see something a bit different:
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
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
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 how to specify a database connection (ideally
On 6/27/07, Mark Ramm [EMAIL PROTECTED] wrote:
Yea, Jonathan has stuff to talk to you about. I think SAContext
could be pretty easily modified to meet his needs. (He wants to share
models between Pylons and other command line tools), but I think
that's a use case we should try to address
Ian Bicking 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'] = manager
try:
app_iter =
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
On 6/27/07, Jonathan LaCour [EMAIL PROTECTED] wrote:
Okay, I am mostly with you, but then you end up with a lot of
boilerplate elsewhere wherever you start a transaction and throw it
into the manager. I think we can address this in the TurboGears pylons
template somehow and automatically
It sounds like Pylons and TurboGears have very different paradigms
about how transactions are handled.
I can't do a side-by-side comparison, because I am not 100% clear on
an example of the right way to handle transactions in Pylons.
But I can describe what TurboGears 1.0 does.
TG currently
On Wednesday 27 June 2007, Mark Ramm wrote:
It sounds like Pylons and TurboGears have very different paradigms
about how transactions are handled.
I can't do a side-by-side comparison, because I am not 100% clear on
an example of the right way to handle transactions in Pylons.
But I can
I hadn't heard of DejaVu until now. One issue with SQLAlchemy is
connect/rollback are buried in the SQL and ORM APIs, so I'm not sure
how useful it would be to shoehorn them into this API which is out of
band from the controller code.
just to clarify, not really. the entire point of
On Jun 27, 8:24 pm, Uwe C. Schroeder [EMAIL PROTECTED] wrote:
And on that note: if you're using SA with TG, SA issues a rollback on every
transaction that is not an insert or update. So if you're having a stored
procedure (which you trigger with select * from stored_proc() and that
stored
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'] = manager
On Jun 27, 7:44 pm, Mike Orr [EMAIL PROTECTED] wrote:
The normal Pylons strategy is to clear the SQLAlchemy session in the
base controller before calling the action method. This is effectively
a rollback, but since all the changes are in memory and haven't been
compiled to SQL yet, no
On Wednesday 27 June 2007, Michael Bayer wrote:
On Jun 27, 8:24 pm, Uwe C. Schroeder [EMAIL PROTECTED] wrote:
And on that note: if you're using SA with TG, SA issues a rollback on
every transaction that is not an insert or update. So if you're having a
stored procedure (which you trigger
55 matches
Mail list logo
