The difficulty with the decorator approach is that, at least in the case of my
"DataError", in the course of executing modelinstance.save(), nobody has
called transaction.set_dirty(), so the commit_on_success decorator's
wrapper doesn't call rollback.
If I caught the error inside of the wrapper,
I'm following you now. I was reading through the transaction.py code after
David's post, and had just come to the same conclusion.
I have a function (called in a loop) that contains all my model get's and saves,
so I tried the commit_on_success decorator. Sadly, the next database
interaction
Bill Freeman wrote:
> How does this apply when there is no request? I'm not following you.
I forgot to say, that I would create a temporary script file which
uses the decorator commit_on_success instead of using "manage.py shell".
Thomas
--
Thomas Guettler, http://www.thomas-guettler.de/
Bill Freeman wrote:
> How does this apply when there is no request? I'm not following you.
>
I wrote:
>> Only methods that are called from the shell (scripts in bin/...) have the
>> commit_on_success decorator.
With shell I mean a unix like shell, cron-job or something like this, where you
On 14/04/10 23:15, Bill Freeman wrote:
The trouble is, I don't know how. Just calling django.db.transaction.rollback()
doesn't work, and neither do several other guesses.
N.B. Despite eventually signalling a TransactionManagementError if
django doesn't "think" it's in a
How does this apply when there is no request? I'm not following you.
Bill
On Thu, Apr 15, 2010 at 4:20 AM, Thomas Guettler wrote:
> Hi,
>
> here is the way I do it: I use the TransactionMiddleware. Every request gets
> commited or rollbacked (A of ACID (atomar)).
>
> Only
Yes. I saw that in the implementation of django.db.transaction.rollback().
I hesitate to use "private" methods, but since it's an odd requirement, I
may well go this way.
Thanks,
Bill
On Wed, Apr 14, 2010 at 7:25 PM, Joe wrote:
> On Apr 14, 6:15 pm, Bill Freeman
Hi,
here is the way I do it: I use the TransactionMiddleware. Every request gets
commited or rollbacked (A of ACID (atomar)).
Only methods that are called from the shell (scripts in bin/...) have the
commit_on_success decorator.
If methods get used from the shell and from views, they do not
On Apr 14, 6:15 pm, Bill Freeman wrote:
> I'm running code from the manage.py shell to load stuff (from an XML export
> from
> an excel read of a SQL Server dump, of all things), which gets a database
> error
> (Postgersql correctly noticing that a value is too long for a
9 matches
Mail list logo