> 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
On Tue, May 18, 2010 at 12:45 AM, SmileyChris wrote:
> Can't investigate too much more until tomorrow, but it's a pretty big
> regression so I thought I'd bring it up here for discussion as well as
> starting a ticket.
>
> http://code.djangoproject.com/ticket/13556
>
I cannot recreate given the
Can't investigate too much more until tomorrow, but it's a pretty big
regression so I thought I'd bring it up here for discussion as well as
starting a ticket.
http://code.djangoproject.com/ticket/13556
--
You received this message because you are subscribed to the Google Groups
"Django develop
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
Congratulations to all the developers who worked on 1.2, it's a
fabulous release.
P.S. It's sad but I'm almost as excited by the dropping of python 2.3
as I am the real features. Almost.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To p
Hi Djangonauts,
I'd like to call attention to a patch[0] I submitted last week for
#6870[1]. From one perspective, this ticket is a version of the "My
models with foreign keys are deleted when their related model deletes
because of Django's ON CASCADE DELETE behavior." But from another
perspecti
On Mon, May 17, 2010 at 5:29 PM, Alex Gaynor wrote:
> On Mon, May 17, 2010 at 10:00 AM, Charlie Nolan
> wrote:
> > It seems to me like the biggest problem with a settings module not
> > importing is that it's not safe to display a full error message about
> > that file. You can't tell if DEBUG
We're pleased today to announce the release of both Django 1.1.2 --
the second bugfix release in the 1.1 series -- and the long-awaited
Django 1.2.
More information is available over at djangoproject.com:
* Django 1.1.2 release announcement:
http://www.djangoproject.com/weblog/2010/may/17/112/
*
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
On Mon, May 17, 2010 at 10:00 AM, Charlie Nolan wrote:
> It seems to me like the biggest problem with a settings module not
> importing is that it's not safe to display a full error message about
> that file. You can't tell if DEBUG is on, and there may well be
> information in the settings that
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!
>
>
It seems to me like the biggest problem with a settings module not
importing is that it's not safe to display a full error message about
that file. You can't tell if DEBUG is on, and there may well be
information in the settings that is a Bad Idea to leak on a production
server.
Also, as a friend
This also caused some heartache for me. I opened a ticket with a
simple patch here: http://code.djangoproject.com/ticket/13043. I'm
sure something more elaborate could be done, but simply printing the
ImportError in the console has been all I've needed thus far. Perhaps
you could update this tic
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
16 matches
Mail list logo
