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 5 mars 2013, at 20:35, Michael Manfre wrote:
> - Less popular database backends may get left behind
To be honest, I wouldn't make any effort to keep the MySQL and Oracle backends
at feature-parity with PostgreSQL and SQLite if they weren't in core.
--
Aymeric.
--
You received this me
Hi Florian,
On Tue, Mar 5, 2013 at 7:01 PM, Florian Apolloner wrote:
> I am obviously biased against postgres as my previous post indicated, but
> regardless of that I think that MSSQL should stay outside of core. No
> core-developer I know actually uses Windows as base OS and to my knowledge
> n
Le mardi 5 mars 2013 20:35:07 UTC+1, Michael Manfre a écrit :
>
> Full disclosure, I maintain django-mssql and am biased toward having all
> database backends treated as if they were 3rd party backends.
>
The question is, how monolithic do we want to have Django?
If we would move database back
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 Tuesday, March 5, 2013 11:01:01 PM UTC+1, Florian Apolloner wrote:
>
> I am obviously biased against postgres as my previous post indicated, but
> regardless of that I think that MSSQL should stay outside of core. No
> core-developer I know actually uses Windows as base OS and to my knowledg
Hi Shai,
On Tuesday, March 5, 2013 10:32:29 PM UTC+1, Shai Berger wrote:
>
> In recent years, I have been the main contributor to South's MSSQL and
> Oracle
> backends. I am biased towards having MSSQL treated as an equal to the
> database
> systems supported in core, but also towards support
Hi,
On Tuesday 05 March 2013, Michael Manfre wrote:
> Full disclosure, I maintain django-mssql and am biased toward having all
> database backends treated as if they were 3rd party backends.
>
In recent years, I have been the main contributor to South's MSSQL and Oracle
backends. I am biased to
Hi,
On Tuesday, March 5, 2013 8:35:07 PM UTC+1, Michael Manfre wrote:
>
> The current discussion about "Switch to database-level autocommit" (
> http://bit.ly/ZlVERI) reminded me of a past discussion regarding moving
> the database backends out of the core. I don't remember exactly where I
> hea
Full disclosure, I maintain django-mssql and am biased toward having all
database backends treated as if they were 3rd party backends.
The current discussion about "Switch to database-level autocommit" (
http://bit.ly/ZlVERI) reminded me of a past discussion regarding moving the
database backends
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 Monday 04 March 2013, John Baker wrote:
> Hey I am currently working on a geolocation based game that utilizes a
> geodjango application to manage querying, parsing, and server geographical
> data to our client. We are currently using PostGIS to store our OSM data.
> We are using the OSM tilenam
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
Since the consensus as shifted toward not making a break-everything 2.0 I'm
planning to normalize the queryset methods name early in the 1.6
development cycle to spot any breakages.
The affected classes are the following:
- *django.contrib.admin.options.BaseModelAdmin* (*queryset* ->
24 matches
Mail list logo
