On Wednesday 06 March 2013, Aymeric Augustin wrote:
>
> So part 3 of the plan is to replace TransactionMiddleware by something
> based on transaction.atomic that actually works. For lack of a better
> idea, I'm considering deprecating the middleware and replacing it with a
> setting. This doesn't
On 6 mars 2013, at 23:21, Aymeric Augustin
wrote:
> using a WSGI middleware. It's two lines of code:
>
> from django.core.wsgi import get_wsgi_application
> application = get_wsgi_application()
>
> for db in ('default', 'other'):
> application = atomic(using=db)(application)
>
> I'm lean
To clarify a little bit, the reasons I think it's a good idea are because:
* It's simple and clean.
* It doesn't require another setting, nor new middleware methods, nor
new anything actually.
* It makes Django inter-op a tiny bit better (if you want to use
Django's ORM and request-linked commits
On 5 mars 2013, at 23:13, Aymeric Augustin
wrote:
> For lack of a better idea, I'm considering deprecating the middleware and
> replacing it with a setting. This doesn't qualify as loose coupling; better
> ideas welcome!
Jacob just suggested on IRC using a WSGI middleware. It's two lines of
On Wed, Mar 6, 2013 at 4:15 AM, Jeremy Dunck wrote:
> I, for one, would prefer that we not recommend TransactionMiddleware
> so highly.
then what would be the recommended option to have transactions tied to
the request/response cycle?
probably @commit_on_success for every view that modifies the
On Wednesday, 6 March 2013 16:12:18 UTC+7, jdunck wrote:
>
> Can
> you give a concrete example of an exception being raised at commit
> time?
>
Postgres allows for things like foreign key integrity checks to be made on
commit (rather than when the data is entered). This makes it significantl
On 6 mars 2013, at 08:49, Ian Kelly wrote:
> On Tue, Mar 5, 2013 at 3:13 PM, Aymeric Augustin
> wrote:
>> In the mean time, I discovered that it's impossible to implement
>> TransactionMiddleware reliably as a middleware, because there's no guarantee
>> that process_response or process_exception
I, for one, would prefer that we not recommend TransactionMiddleware
so highly. Now that I'm doing active development with Rails, it's
quite clear to me that a major difference in the ORM layers are which
DB they grew up with -- the django orm is tuned best to postgres,
while working passably on m
I'm not sure what you're referring to here - integrity, uniqueness,
and locking are handled at the individual query level - transactions
just cause locks to be held (if needed) until commit or rollback. Can
you give a concrete example of an exception being raised at commit
time?
On Tue, Mar 5, 2
On Mon, Mar 4, 2013 at 1:34 AM, Aymeric Augustin
wrote:
> On 4 mars 2013, at 01:07, Shai Berger wrote:
...
>> The use of savepoints in Django apps so far has been very little, as far as
>> I know. One point
>> I'm unsure of is the interaction of savepoints with cursors, since querysets
>> are l
On Wednesday, March 6, 2013 8:49:37 AM UTC+1, Ian wrote:
>
> On Tue, Mar 5, 2013 at 3:13 PM, Aymeric Augustin
> > wrote:
> > In the mean time, I discovered that it's impossible to implement
> > TransactionMiddleware reliably as a middleware, because there's no
> guarantee
> > that process_resp
On Tue, Mar 5, 2013 at 3:13 PM, Aymeric Augustin
wrote:
> In the mean time, I discovered that it's impossible to implement
> TransactionMiddleware reliably as a middleware, because there's no guarantee
> that process_response or process_exception will be called.
Perhaps this could be fixed. We c
Hi Ian, Aymeric and all,
I stand corrected.
On Tuesday 05 March 2013, Ian Kelly wrote:
> On Tue, Mar 5, 2013 at 6:38 AM, Shai Berger wrote:
> >
> > When Django checks for a second record on get() it reads the second
> > record, so a repeatable-read transaction would acquire an exclusive read
>
On 3 mars 2013, at 21:37, Aymeric Augustin
wrote:
> Part 2 of the plan is more ambitious — it's about improving the transaction
> APIs. Here's the general idea.
>
> I'd like to add an @atomic decorator that:
> - Really guarantees atomicity, by raising an exception if you attempt
> commi
On Tue, Mar 5, 2013 at 4:42 AM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> In practice, this would mean:
> - Define "hook points" that are a superset the old and the new APIs.
> - Re-implement the current transaction management with these "hook points"
> (hard, because the i
On Tue, Mar 5, 2013 at 6:38 AM, Shai Berger wrote:
> I'm not sure what you mean by "unsafe".
>
> Version 1: code in the question
>
> rows = MyModel.objects.all()
> for row in rows:
> try:
> MyModel.objects.get(photo_id=row.photo_id)
> except:
Hi Lennart,
On Tue, 5 Mar 2013, Lennart Regebro wrote:
I do agree that 99.9% of the sites committing on the end of the request
is the right thing to do, and do think that this should be the default,
although I realize that debate is already lost.
In a perfect academic world where there are n
On Tuesday 05 March 2013, Aymeric Augustin wrote:
>
> In practice, this would mean:
> - Define "hook points" that are a superset the old and the new APIs.
> - Re-implement the current transaction management with these "hook points"
> (hard, because the intended behavior of the dirty flag isn't c
On Tuesday 05 March 2013, Aymeric Augustin wrote:
> On 5 mars 2013, at 12:50, Shai Berger wrote:
> > At least the "delete duplicates" example I've pointed to shows, that it's
> > quite easy to write code that is correct now, under the defaults, with
> > MySql and will break with the change.
>
> h
On 5 mars 2013, at 07:37, Lennart Regebro wrote:
> I do agree that 99.9% of the sites committing on the end of the
> request is the right thing to do, and do think that this should be the
> default, although I realize that debate is already lost.
Well, it's possible to enable TransactionMiddlew
On Fri, Mar 1, 2013 at 4:11 PM, Alex Gaynor wrote:
> FWIW: any sort of scheme where a transaction is kept open all request
> (including a transaction that only ever reads), will cause you serious pain
> if you're trying to do migrations on MySQL with traffic.
Wouldn't the transaction be opened wh
On 5 mars 2013, at 12:50, Shai Berger wrote:
> At least the "delete duplicates" example I've pointed to shows, that it's
> quite easy to write code that is correct now, under the defaults, with MySql
> and will break with the change.
http://stackoverflow.com/questions/8965391/delete-duplicate-
On Tuesday 05 March 2013, Aymeric Augustin wrote:
> On 5 mars 2013, at 01:50, Shai Berger wrote:
> > I want to point out how ironic this whole issue turns out.
>
> That's a storm in a teapot. Let's keep some perspective:
I really had no intentions of disrupting the weather; however,
> - People
On 5 mars 2013, at 02:28, Shai Berger wrote:
> This is just a half-baked idea; I suspect those of you who are more well-
> versed in the current implementation of transaction management, and who put
> some thought into this, may be able to shoot it down easily. But here goes.
>
> Basically, tra
On 5 mars 2013, at 01:50, Shai Berger wrote:
> I want to point out how ironic this whole issue turns out.
That's a storm in a teapot. Let's keep some perspective:
- People using MyISAM aren't affected.
- People using the transaction middleware aren't affected.
- People using commit_on_success a
Hi Florian and everybody,
On Sunday 03 March 2013, Florian Apolloner wrote:
> On Sunday, March 3, 2013 12:27:47 AM UTC+1, Shai Berger wrote:
> > > I also believe that it beats the alternative — namely, live with the
> > >
> > > current behavior forever.
> >
> > I sincerely hope [...] that there'
Hi,
On Monday 04 March 2013, Aymeric Augustin wrote:
> On 4 mars 2013, at 04:04, Shai Berger wrote:
> > you need to be sure that, in all these places, either reads don't
> > really affect consequent writes, or some constraint holds that is
> > equivalent to serializability -- otherwise, negative
On Mar 4, 2013, at 7:24 AM, Aymeric Augustin wrote:
> PostgreSQL and Oracle use the "read committed" ...
Sorry, replied too soon!
> The reasoning and the conclusion still stand.
Agreed.
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to th
On Mar 4, 2013, at 5:00 AM, Aymeric Augustin wrote:
> PostgreSQL and Oracle use the "repeatable read" isolation level by default.
Without explicitly changing it, PostgreSQL's default is READ COMMITTED. Or are
we setting it explicitly to REPEATABLE READ in the new model?
--
-- Christophe Pettu
On 4 mars 2013, at 16:04, Andrey Antukh wrote:
> If not I'am wrong, postgresql uses "read commited" by default and mysql
> "repeatable read"
Sorry, I swapped the isolation level names when I wrote the explanation. The
correct version is:
PostgreSQL and Oracle use the "read committed" ...
MyS
Hi,
On Monday, March 4, 2013 2:00:03 PM UTC+1, Aymeric Augustin wrote:
>
> PostgreSQL and Oracle use the "repeatable read" isolation level by
> default.
According to http://www.postgresql.org/docs/9.1/static/transaction-iso.html
PG uses "read commited" as default.
> MySQL uses "read commit
If not I'am wrong, postgresql uses "read commited" by default and mysql
"repeatable read"
http://www.postgresql.org/docs/9.1/static/transaction-iso.html -> "Read
Committed is the default isolation level in PostgreSQL. "
http://dev.mysql.com/doc/refman/5.0/en/innodb-transaction-model.html -> "In
te
On 4 mars 2013, at 04:04, Shai Berger wrote:
> you need to be sure that, in all these places, either reads don't
> really affect consequent writes, or some constraint holds that is equivalent
> to
> serializability -- otherwise, negative effect is possible.
PostgreSQL and Oracle use the "repe
On 4 mars 2013, at 01:07, Shai Berger wrote:
>> On 1 mars 2013, at 13:48, Aymeric Augustin
>> wrote:
>>
>> I'd like to add an @atomic decorator that:
>> - Really guarantees atomicity, by raising an exception if you attempt
>> commit within an atomic block,
>
> Fragility alert: databases
On Sunday 03 March 2013, Jacob Kaplan-Moss wrote:
> Shai: do you have any real-world code that'd have data loss
> with this bug?
The code in sites I work on usually uses transaction middleware or
@commit_on_success, so it would not suffer (nor benefit) from this change. So I
tried to look for op
Hi,
Here's some thoughts on possible problems with Aymeric's plan. I like
the look of the suggested transaction API, I'm raising these to help
make sure it can be realized.
On Sunday 03 March 2013, Aymeric Augustin wrote:
> On 1 mars 2013, at 13:48, Aymeric Augustin
> wrote:
>
> I'd like to ad
On 1 mars 2013, at 13:48, Aymeric Augustin
wrote:
> Basically, Django intends to provide autocommit by default. Rather than fight
> the database adapter that itselfs fights the database, I propose to simply
> turn autocommit on, and stop implicitly starting and committing transactions.
> Expl
On Mar 3, 2013, at 10:13 AM, Aymeric Augustin wrote:
> In practice, the solution is probably called @xact. Applying it to each
> public ORM function should do the trick. Therefore, I'd like to ask your
> permission to copy it in Django. Technically speaking, this means relicensing
> it from Po
On 3 mars 2013, at 17:09, Christophe Pettus wrote:
> Right now, the only real example I've heard (there might be more is):
>
> 1. The ORM generates multiple updating operations for a single API-level
> operation.
> 2. The developer did nothing to manage their transaction model (no decorator,
>
On Mar 2, 2013, at 3:49 PM, Jacob Kaplan-Moss wrote:
> I'm with Aymeric: the current behavior is bad enough, and this is a
> big enough improvement, and the backwards-incompatibility is minor
> enough.
Right now, the only real example I've heard (there might be more is):
1. The ORM generates mul
Hi Shai,
On Sunday, March 3, 2013 12:27:47 AM UTC+1, Shai Berger wrote:
>
> > I also believe that it beats the alternative — namely, live with the
>
> > current behavior forever.
>
>
> I sincerely hope that is not the only alternative; that there's a way to
> implement the new behavior side-b
On Sat, Mar 2, 2013 at 3:27 PM, Shai Berger wrote:
>> I believe that the level of backwards-incompatibility described above is
>> within acceptable bounds for Django 1.6.
>
> I believe this is the core of our disagreement here.
I'm with Aymeric: the current behavior is bad enough, and this is a
b
Hi again,
On Sunday 03 March 2013, Aymeric Augustin wrote:
> On 2 mars 2013, at 21:46, Shai Berger wrote:
> > The Django documentation on transactions, at the moment says this on
> > Django's
> >
> > default behavior[0]:
> >> Django’s default behavior is to run with an open transaction which it
On 2 mars 2013, at 21:46, Shai Berger wrote:
> The Django documentation on transactions, at the moment says this on Django's
> default behavior[0]:
>
>> Django’s default behavior is to run with an open transaction which it
>> commits automatically when any built-in, data-altering model function
On Saturday 02 March 2013, Aymeric Augustin wrote:
> On 2 mars 2013, at 16:18, Shai Berger wrote:
> > -1. Make it easier (and cross-backend) to set db-level-autocommit on. Put
> > the setting for it in the default template for new projects. Don't
> > change existing code from "fragile" to "subtly
On 2 mars 2013, at 16:18, Shai Berger wrote:
> -1. Make it easier (and cross-backend) to set db-level-autocommit on. Put the
> setting for it in the default template for new projects. Don't change
> existing
> code from "fragile" to "subtly broken".
This isn't simply about changing some defau
On 2 mars 2013, at 15:50, Shai Berger wrote:
> There is an issue you seem to be ignoring: An "ORM Write" is, in many cases,
> more than a single query against the backend. The most obvious example is
> models with inheritance -- trying to do these with database-level autocommit
> means that th
Thinking again, a few more points come to mind:
On Friday 01 March 2013, Aymeric Augustin wrote:
>
> Such transactions are useless and don't come for free. Relying on them to
> enforce integrity is extremely fragile — what if an external library
> starts writing to a log table in the middle of one
On Friday 01 March 2013, Aymeric Augustin wrote:
> Hello,
>
> I'd like to improve transactions handling in Django. The first step is [to
> replace -- assumed, SB] the current emulation of autocommit with
> database-level autocommit.
>
There is an issue you seem to be ignoring: An "ORM Write" is,
> I'd like to improve transactions handling in Django. The first step is the
> current emulation of autocommit with database-level autocommit.
>
[...]
> I don't see much point in providing an option to turn autocommit off,
> because starting a transaction is a much more explicit way to achie
On 1 maalis, 14:48, Aymeric Augustin
wrote:
> Yay or nay?
+1.
I discussed this on IRC with Aymeric. I tried to find cases where this
breaks currently working code, and I was mostly unsuccessful. It seems
there could be such cases (doing raw SQL writes, commit at end, and no
ORM writes, all this
Hey Aymeric -
Yes, I think this is the right thing to do: +1.
Jacob
On Fri, Mar 1, 2013 at 4:48 AM, Aymeric Augustin
wrote:
> Hello,
>
> I'd like to improve transactions handling in Django. The first step is the
> current emulation of autocommit with database-level autocommit.
>
> ** Rationale
On Mar 1, 2013, at 4:48 AM, Aymeric Augustin wrote:
> Yay or nay?
+1.
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an e
+1 from me. Here's a patch to add autocommit to MySQL:
https://github.com/django/django/pull/857
FWIW: any sort of scheme where a transaction is kept open all request
(including a transaction that only ever reads), will cause you serious pain
if you're trying to do migrations on MySQL with traffic
On 03/01/2013 05:48 AM, Aymeric Augustin wrote:
> Basically, Django intends to provide autocommit by default. Rather than
> fight the database adapter that itselfs fights the database, I propose
> to simply turn autocommit on, and stop implicitly starting and
> committing transactions. Explicit is
On 1 mars 2013, at 14:38, Javier Guerra Giraldez wrote:
> On Fri, Mar 1, 2013 at 7:48 AM, Aymeric Augustin
> wrote:
>> To alleviate the pain, Django commits after each ORM write.
>
> just curious: why is it so? i can't think of any reason not to tie
> transaction to the request/response cycl
On Fri, Mar 1, 2013 at 7:48 AM, Aymeric Augustin
wrote:
> To alleviate the pain, Django commits after each ORM write.
just curious: why is it so? i can't think of any reason not to tie
transaction to the request/response cycle by default. (ie what
TransactionMiddleware does).
this is the defa
Yay (+1) and preferably ASAP to get it tested by users right now.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups
On Friday, March 1, 2013 at 7:48 AM, Aymeric Augustin wrote:
> Hello,
>
> I'd like to improve transactions handling in Django. The first step is the
> current emulation of autocommit with database-level autocommit.
>
> ** Rationale **
>
> PEP249 says that any SQL query opens a transaction an
Hello,
I'd like to improve transactions handling in Django. The first step is the
current emulation of autocommit with database-level autocommit.
** Rationale **
PEP249 says that any SQL query opens a transaction and that it's the
application's job to commit (or rollback) changes. This model
60 matches
Mail list logo
