Michael Bayer wrote:
> On Apr 4, 2007, at 7:20 PM, Shannon -jj Behrens wrote:
>
>
>> I call flush in my parent class controller.
>>
>> I have one controller where I need to try to flush before the method
>> is done because I need to be sure the user has picked a unique
>> username. The code looks like:
>>
>> class Continue(Exception):
>> pass
>> ...
>> # Update the dbsession.
>> ...
>> try:
>> self.dbsession.flush()
>> c.action_results = "Account updated."
>> raise Continue
>> except SQLError, e:
>> try:
>> is_duplicate_entry = \
>> e.orig.args[1].startswith("Duplicate entry")
>> if not is_duplicate_entry:
>> raise ValueError
>> except (AttributeError, IndexError, ValueError),
>> ignored:
>> raise e # We can't handle e. Re-
>> raise it.
>> else:
>> c.action_results = """\
>> Sorry, that email address has already been taken."""
>> self.dbsession.clear()
>> if not request.environ.has_key('paste.testing'):
>> time.sleep(2) # Prevent directory harvest
>> attacks.
>> raise Continue
>>
>> except Continue:
>> return render_response('account')
>>
>> I think this is fine.
>>
>> Does that make sense to you?
>>
>
>
> is that your controller code ? seems pretty explicit, which is fine
> because thats what you needed there. but im looking for just your
> basic "add"/"edit" methods, that just load some objects, change them
> around, and its done. would rather not have *any* explicit step that
> has to be repeated in controller methods for a basic flush/commit
> (other than a decorator). otherwise it basically means putting
> "session.flush()" at the end of every controller right above the
> "return" and id rather not have to do that...not just for appearance,
> but also because abstracting away the transactional strategy it
> leaves room for it to be tuned/modified at the library/
> configurational level.
>
For single saves/updates/deletes, I have a helper db class which does
the flush automatically (as well as auto session context) eg.
db.save(myobject), db.delete(myobject). This is how I remove the flush
in my controller. (I'm surprised SA doesn't have such a helper class,
objectstore was almost what I needed, except for the auto save() it did
to newly created objects; my db object is pretty much objectstore,
without the auto save).
For the complex cases with multiple queries/updates/deletes, I create
dao methods (in a seperate module) which I wrap with a transaction
decorator similar to one you specify above.
IMO flushing needs to be controlled explicitly by the programmer because
we need the flexibility to catch errors and react accordingly within the
context of the current controller (unless of course you have a fixed
flow to your programs eg. on error always display this page).
Huy
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
