Ian, thanks for the feedback, but what your concern is not related to
this proposal.
What you're talking about is issuing a BEGIN while already in a database
transaction, which is normally an error, with no standard meaning or
definition in SQL's transaction model. It's completely up to the
datab
> Yes: we're talking about Django's transaction management layer (that is, the
> code in django.db.transaction), which controls how Python-level transaction
> blocks map to SQL transactions.
>
> The original email and writeup has a full explanation. :)
>
Yes. What I was getting at is that django's
2010/5/18 Ian Lewis :
> Am I missing something? Are we talking about doing some kind of
> transaction management at the application level?
Yes: we're talking about Django's transaction management layer (that is, the
code in django.db.transaction), which controls how Python-level transaction
blocks
I should probably be more specific. Without using savepoints nested
transaction functionality couldn't be achieved with MySQL (and only
with InnoDB). START TRANSACTION does an implicit commit so the
previous transaction is not subsumed.
I suppose that savepoint based functionality could be impleme
Am I missing something? Are we talking about doing some kind of
transaction management at the application level? If not then it's
worth noting that in MySQL you cannot begin a transaction twice
without commiting or rolling back. i.e. nested transactions are not
supported.
On Tue, May 18, 2010 at 1
2010/5/17 Ian Lewis :
>
> I suppose that it's worth mentioning that any support for nested
> transactions will not be portable to different databases (particularly
> MySQL) and probably would need to be documented accordingly.
How do you mean?
Django-level transaction block nesting is portable to
I suppose that it's worth mentioning that any support for nested
transactions will not be portable to different databases (particularly
MySQL) and probably would need to be documented accordingly.
Ian
On Mon, May 17, 2010 at 7:50 PM, Piet Delport wrote:
> Hi Russel, thanks for the response!
>
>
Hi Russel, thanks for the response!
On May 15, 12:47 pm, Russell Keith-Magee
wrote:
>
> By way of a brief explanation of why things are they way they are:
>
> Firstly, Django's history in journalism-based websites breeds a
> history of high-volume reads, and low-volume, relatively simple
> writes
>
> I wrote up the following document, which describes the problem in a fair
> amount of detail, as well as how Django's transaction management system may
> be fixed to avoid it:
>
> - Django Transaction
> Integrity<http://docs.google.com/View?id=dgxrkmrk_2hmk4fmhg>
&
r example, "Use the commit_on_success decorator to use a
> single transaction for all the work done in a function.")
> I wrote up the following document, which describes the problem in a fair
> amount of detail, as well as how Django's transaction management system may
>
done in a function.")
I wrote up the following document, which describes the problem in a fair
amount of detail, as well as how Django's transaction management system may
be fixed to avoid it:
- Django Transaction
Integrity<http://docs.google.com/View?id=dgxrkmrk_2hmk4fmhg>
I&#
11 matches
Mail list logo
