On Thu, Aug 4, 2011 at 1:37 PM, Chris McDonough <[email protected]> wrote:

> when using transactions, how all-in does
> > one have to go?
>
> I guess in a sense the answer is "none" and "a lot" at the same time.
>
> The transaction machinery provides a hook to do something based on the
> commit status.  If the transaction has aborted, do X; if it has
> committed, do Y.  There's probably second-order details that would need
> to be addressed in any particular integration that uses the after commit
> hook but without seeing code it's hard to make any sort of general
> statement about it.
>

Agreed; time for code. I might be able to take a crack at this.


If you're using ZODB, you have Blob objects, which, although they're not
> documented very well, make file IO 100% transactional.


Yeah, I'm playing with them for the first time, thanks.


No so far. ;-)  But it probably will if it goes on much longer without
> any code being shown.  A codeless conversation seems more suited to be
> had over a beer or in a consulting engagement than to be had over the
> maillist, I think.
>

Right. I would love to buy you a beer; I see from the twitter that you like
strong ales and so-on; my brother runs the local micro-brew supply shop and
I'm in Madison, WI, which is good beer country. I don't think you're in
Madison, WI.

But yeah, time to code.


Maybe.  I really dont know.  I've internalized the transaction pattern
> so much and I've written so much code that relies on synchronization of
> multiple storages via a single commit point that I tend to think of code
> that uses multiple storages and which doesn't use a transaction manager
> as broken by design.


I think this may be my point, just I didn't know how to make it. Only "part"
of Pyramid is transactional, and it's the good parts, but there seems to be
a small bit of leakage, at least on the branch* that I'm following.

(* Pyramid seems to have some branches of common patterns since it's so
flexible: zodb/sqla, traversal/routes, etc.. I'm on the traversal, zodb,
pyramid_mailer, pyramid_deform, pyramid_beaker path )


Those things above sound reasonable.  (FTR, that's not me volunteering
> to do them right now, just an agreement they sound reasonable and
> deserve an entry in some TODO).


So noted. For The Record.

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