Re: class based views: object instead of dictionary as context?

[Jacob Kaplan-Moss]

On Fri, Sep 2, 2011 at 4:15 PM, Greg Donald  wrote:
> Clearly you've been working with some hybrid wanna-be designers who
> probably don't do any heavy lifting in either realm.

Greg, I hope and am going to assume you're joking. If not -- and
remember with email it can hard to tell -- this comes across as
super-insulting.

Either way, you guys are way off topic at this point. Take it to
private email, please.

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: class based views: object instead of dictionary as context?

[Greg Donald]

On Fri, Sep 2, 2011 at 11:35 AM, Carl Meyer  wrote:
> But please lay off the overblown rhetoric. I can name fifteen designers
> who code off the top of my head (more than I could name who don't).

Clearly you've been working with some hybrid wanna-be designers who
probably don't do any heavy lifting in either realm.


-- 
Greg Donald

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Race condition in get_or_create

[Jeremy Dunck]

We've been running in prod without trouble under 'read committed' for
about a week, though not under heavy load -- it's a fairly new site.

I'm not sure how much assurance I can offer at higher load, sorry.

On Fri, Sep 2, 2011 at 11:42 AM, Ian Clelland  wrote:
>
>
> On Fri, Sep 2, 2011 at 11:22 AM, Jeremy Dunck  wrote:
>>
>> On Fri, Sep 2, 2011 at 11:04 AM, Ian Clelland  wrote:
>> > I'm seeing errors which I believe are due to a race condition in
>> > django.db.models.query.get_or_create, on a fairly high traffic site. Our
>> > production servers are running Django 1.2.5, but I don't see any changes
>> > in
>> > the code in trunk that would affect this. (I'm totally willing to
>> > construct
>> > a test case against trunk, but I'm posting this here in case it's
>> > already a
>> > recognized bug, or an error on my part)
>> > If two requests make the same call to get_or_create(), at roughly the
>> > same
>> > time, with a database server in REPEATABLE_READ isolation level, then I
>> > believe that it's possible for the following sequence of events to
>> > occur:
>>
>> I suspect you're using MySQL.  Am I right?  We just switched a mysql
>> site from repeatable read (the default) to read committed (postgres's
>> default, hence a better-tested path in django) for this very reason.
>
> We are. 5.0.51a, I believe.
> READ COMMITTED would definitely solve this -- that seems to be the main
> point behind #13906, but there seems to be some resistance there. Have you
> encountered any other issues from making that switch?
>
> Regards,
> Ian Clelland
> 
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Race condition in get_or_create

[Ian Clelland]

On Fri, Sep 2, 2011 at 11:22 AM, Jeremy Dunck  wrote:

> On Fri, Sep 2, 2011 at 11:04 AM, Ian Clelland  wrote:
> > I'm seeing errors which I believe are due to a race condition in
> > django.db.models.query.get_or_create, on a fairly high traffic site. Our
> > production servers are running Django 1.2.5, but I don't see any changes
> in
> > the code in trunk that would affect this. (I'm totally willing to
> construct
> > a test case against trunk, but I'm posting this here in case it's already
> a
> > recognized bug, or an error on my part)
> > If two requests make the same call to get_or_create(), at roughly the
> same
> > time, with a database server in REPEATABLE_READ isolation level, then I
> > believe that it's possible for the following sequence of events to occur:
>
> I suspect you're using MySQL.  Am I right?  We just switched a mysql
> site from repeatable read (the default) to read committed (postgres's
> default, hence a better-tested path in django) for this very reason.
>

We are. 5.0.51a, I believe.
READ COMMITTED would definitely solve this -- that seems to be the main
point behind #13906, but there seems to be some resistance there. Have you
encountered any other issues from making that switch?


Regards,
Ian Clelland


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Race condition in get_or_create

[Jeremy Dunck]

On Fri, Sep 2, 2011 at 11:04 AM, Ian Clelland  wrote:
> I'm seeing errors which I believe are due to a race condition in
> django.db.models.query.get_or_create, on a fairly high traffic site. Our
> production servers are running Django 1.2.5, but I don't see any changes in
> the code in trunk that would affect this. (I'm totally willing to construct
> a test case against trunk, but I'm posting this here in case it's already a
> recognized bug, or an error on my part)
> If two requests make the same call to get_or_create(), at roughly the same
> time, with a database server in REPEATABLE_READ isolation level, then I
> believe that it's possible for the following sequence of events to occur:

I suspect you're using MySQL.  Am I right?  We just switched a mysql
site from repeatable read (the default) to read committed (postgres's
default, hence a better-tested path in django) for this very reason.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Race condition in get_or_create

[Ian Clelland]

And, of course, immediately after posting this, I find
http://code.djangoproject.com/ticket/13906, which seems to cover much of the
same area.

Ian


On Fri, Sep 2, 2011 at 11:04 AM, Ian Clelland  wrote:

> I'm seeing errors which I believe are due to a race condition in
> django.db.models.query.get_or_create, on a fairly high traffic site. Our
> production servers are running Django 1.2.5, but I don't see any changes in
> the code in trunk that would affect this. (I'm totally willing to construct
> a test case against trunk, but I'm posting this here in case it's already a
> recognized bug, or an error on my part)
>
> If two requests make the same call to get_or_create(), at roughly the same
> time, with a database server in REPEATABLE_READ isolation level, then I
> believe that it's possible for the following sequence of events to occur:
>
> 1. Process 1 enters into a transaction as part of the default view
> middleware.
> 2. Process 1 calls QuerySet.get(**lookup), no result is returned.
> (DoesNotExist is raised)
> 
> 3. Process 2 enters into a transaction as part of the default view
> middleware.
> 4. Process 2 calls QuerySet.get(**lookup), no result is
> returned. (DoesNotExist is raised)
> 5. Process 2 calls transaction.savepoint
> 6. Process 2 saves a new object
> 7. Process 2 commits and returns the object
> 
> 8. Process 1 calls transaction.savepoint
> 9. Process 1 tries to save a new object; this locks before #7, above, and
> fails after #7, with an IntegrityError
> 10. Process 1 rolls back to the savepoint, *but does not leave the outer
> transaction*
> 11. Process 1 calls QuerySet.get(**lookup), again, *but because we're still
> in the outer transaction, this returns nothing*
> 12. Process 1 Raises an integrity error, rather than getting the new
> object.
>
> Process 1 fails, because it performed the initial read inside of a
> transaction, but before the save point. In fact, inside of the same
> transaction, I believe it is impossible for the initial self.get() and the
> self.get() in the exception handler to return different results.
>
> Some SQL-shell testing shows that it's possible for this to work, as long
> as we set the savepoint before the initial read. That way, when we catch an
> IntegrityError and roll back to the savepoint, the lock is released, and
> Process 1 can actually see the object committed by Process 2.
>
> I expect to open up a ticket for this, unless someone can tell me "you're
> doing it wrong", or point me to another ticket (I've scanned the trac
> database, but didn't see anything identical. 15507 touches this, but won't
> actually do anything to solve it.)
>
> --
> Regards,
> Ian Clelland
> 
>



-- 
Regards,
Ian Clelland


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Race condition in get_or_create

[Ian Clelland]

I'm seeing errors which I believe are due to a race condition in
django.db.models.query.get_or_create, on a fairly high traffic site. Our
production servers are running Django 1.2.5, but I don't see any changes in
the code in trunk that would affect this. (I'm totally willing to construct
a test case against trunk, but I'm posting this here in case it's already a
recognized bug, or an error on my part)

If two requests make the same call to get_or_create(), at roughly the same
time, with a database server in REPEATABLE_READ isolation level, then I
believe that it's possible for the following sequence of events to occur:

1. Process 1 enters into a transaction as part of the default view
middleware.
2. Process 1 calls QuerySet.get(**lookup), no result is returned.
(DoesNotExist is raised)

3. Process 2 enters into a transaction as part of the default view
middleware.
4. Process 2 calls QuerySet.get(**lookup), no result is
returned. (DoesNotExist is raised)
5. Process 2 calls transaction.savepoint
6. Process 2 saves a new object
7. Process 2 commits and returns the object

8. Process 1 calls transaction.savepoint
9. Process 1 tries to save a new object; this locks before #7, above, and
fails after #7, with an IntegrityError
10. Process 1 rolls back to the savepoint, *but does not leave the outer
transaction*
11. Process 1 calls QuerySet.get(**lookup), again, *but because we're still
in the outer transaction, this returns nothing*
12. Process 1 Raises an integrity error, rather than getting the new object.

Process 1 fails, because it performed the initial read inside of a
transaction, but before the save point. In fact, inside of the same
transaction, I believe it is impossible for the initial self.get() and the
self.get() in the exception handler to return different results.

Some SQL-shell testing shows that it's possible for this to work, as long as
we set the savepoint before the initial read. That way, when we catch an
IntegrityError and roll back to the savepoint, the lock is released, and
Process 1 can actually see the object committed by Process 2.

I expect to open up a ticket for this, unless someone can tell me "you're
doing it wrong", or point me to another ticket (I've scanned the trac
database, but didn't see anything identical. 15507 touches this, but won't
actually do anything to solve it.)

-- 
Regards,
Ian Clelland


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: ticket 13125 is waiting for a design decision for 18 months

[David Danier]

> Description:
> "The login_required decorator is not checking User.is_active, as
> staff_member_required does. If an authenticated user is deactivated
> (via setting is_active to False), the user is still able to browse
> login_required-protected views."
> For probably most people, the expected and (most likely) wanted
> behavior would be not to let inactive users have access to
> login_required files.

I actually had my problems with this some time ago, too. Meaning I
wanted to disable users via setting is_active=False. Back then I just
though this was stupid.

But a while later I discovered a not so uncommon usecase for the
login_required behavior which may be the reason this still is in design
decision state:
Many websites force their users to activate using email verification.
Many of those also login their users after registration (as an
is_active=False-user). This way the user gets logged in successfuly but
may never login again before going through email verification.

I myself have code which relies on this behavior. So I think just
changing it may break some websites. Anyway I still think this is not
what people expect, so either this needs to be documented ("WARNING:
...") or changed in a backwards compatible way (e.g. add a parameter to
login_required).

David

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: class based views: object instead of dictionary as context?

[Carl Meyer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/02/2011 01:01 AM, Greg Donald wrote:
> Planning for designers to work in code is an extreme edge case.  In 15
> years of web development I've never once worked with a single designer
> who was interested in touching any code.  As far as my own web
> projects go, the designer is done the moment they give me a layered
> .psd.

Please be careful with the unwarranted generalizations based on your
personal experience. I'm sure there are designers who never go beyond
the PSD, but my personal experience happens to be the opposite - I've
never worked with a web designer who didn't handle all of the HTML, CSS,
and templates themselves; almost all of the designers I know are
perfectly competent in front-end coding (and some in Python, too). It
seems a bit rude to dismiss them all as an "extreme edge case." If you'd
like to broaden your horizons, I'd be happy to recommend some names ;-)

> How is something like {{ view.myvar }} any harder than {{ myvar }} for
> those two designers in the whole world who actually want to touch the
> code?

I agree that {{ view.myvar }} is just fine.

But please lay off the overblown rhetoric. I can name fifteen designers
who code off the top of my head (more than I could name who don't).

Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5hBdwACgkQ8W4rlRKtE2dmjACfT9EURJhvwTLW/S21ak7TzXvI
U84AoMzbnDACXDf0oTVjtovcen+ybv+6
=Sz6+
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Exceptions thrown from middleware

[Michael Manfre]

I opened ticket #12250 for this exact reason a while ago. It's
currently design decision needed. I'm still in favor of giving
middleware a chance to handle errors raised by middleware.

https://code.djangoproject.com/ticket/12250

Regards,
Michael

On Sep 1, 11:48 am, Tom Evans  wrote:
> Hi all
>
> Currently, if a view throws an exception, the middleware classes that
> have a process_exception method will be called in reverse order to see
> if one of them can handle it and return a valid response before
> django's default exception handling takes over.
>
> This doesn't hold true for middleware classes themselves - any
> exception raised from a middleware's process_{request,view,response}
> is immediately handled by django's default exception handling, and
> there is no way of handling that exception more cleanly.
>
> The use case I saw for this was for a series of exceptions that
> middleware classes could raise, which would then be handled by another
> piece of middleware. As an example, my project has a bunch of
> automatic authenticators - IP based, SAML based, crufty tokens
> produced by Lotus Notes - but they failures in all of them should be
> handled the same. Raising a generic exception in the appropriate
> middleware, and then handling it in another middleware class seemed a
> nice clean way of doing this, I was disappointed when I read
> core/handlers/base.py
>
> It wouldn't be tricky to change this so that exceptions raised from
> middleware can be handled by middleware, but obviously this would be a
> not inconsequential change in behaviour..
>
> Thoughts?
>
> Cheers
>
> Tom

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: class based views: object instead of dictionary as context?

[Reinout van Rees]

On 02-09-11 10:04, Russell Keith-Magee wrote:

To the best of my knowledge, the only reason the view isn't included
in the template context is because over more than two years of design
discussion, I don't think the idea of including the view in the
context was ever proposed.

[...]

Patches welcome;-)


I haven't got a patch (yet), but I at least created a ticket for it: 
https://code.djangoproject.com/ticket/16744



Reinout

--
Reinout van Reeshttp://reinout.vanrees.org/
rein...@vanrees.org http://www.nelen-schuurmans.nl/
"If you're not sure what to do, make something. -- Paul Graham"

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: class based views: object instead of dictionary as context?

[Russell Keith-Magee]

On Fri, Sep 2, 2011 at 3:00 PM, Greg Donald  wrote:
> On Thu, Sep 1, 2011 at 3:46 PM, Reinout van Rees  wrote:
>> why does django encourage a hand-crafted
>> context dictionary instead of "just" passing the view object along?
>
> I think it's the worst part of using Django.  Having to manage a
> context dictionary in every view is weak.

To the best of my knowledge, the only reason the view isn't included
in the template context is because over more than two years of design
discussion, I don't think the idea of including the view in the
context was ever proposed.

It seems like a reasonable idea to me, though, and it should be
possible to accommodate in a backwards compatible fashion. The trivial
fix would be to add a 'view' variable to the default context. It might
also be possible to replace the default get_context_data
implementation with something that reflects the attributes of the view
object  itself -- however, this will obviously require a bit more
design work to make sure there aren't any backwards incompatible
implications.

Patches welcome ;-)

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: class based views: object instead of dictionary as context?

[Russell Keith-Magee]

On Fri, Sep 2, 2011 at 1:25 PM, daonb  wrote:
> Hi Reinout,
>
> IMHO, Django's philosophy is that template designers are highly
> skilled designers and not coders.  To make it possible for designers
> to edit the templates themselves, Django requires the developer to
> create a simple context dictionary for designers to understand.
>
> In all of my projects so far I didn't have the luxury of a designer
> who'se fluent in Django templates and can write them by himself, but
> still, I like Django for showing a clear way for designers and coders
> to work together.

This isn't an especially strong argument against including the view in
the template -- after all, the template language allows dot notation
to explore object attributes. The underlying type is completely opaque
from a template designer's perspective.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: class based views: object instead of dictionary as context?

[Greg Donald]

On Fri, Sep 2, 2011 at 12:25 AM, daonb  wrote:
> IMHO, Django's philosophy is that template designers are highly
> skilled designers and not coders.  To make it possible for designers
> to edit the templates themselves,

Planning for designers to work in code is an extreme edge case.  In 15
years of web development I've never once worked with a single designer
who was interested in touching any code.  As far as my own web
projects go, the designer is done the moment they give me a layered
.psd.

> Django requires the developer to
> create a simple context dictionary for designers to understand.

How is something like {{ view.myvar }} any harder than {{ myvar }} for
those two designers in the whole world who actually want to touch the
code?


-- 
Greg Donald

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: class based views: object instead of dictionary as context?

[Greg Donald]

On Thu, Sep 1, 2011 at 3:46 PM, Reinout van Rees  wrote:
> why does django encourage a hand-crafted
> context dictionary instead of "just" passing the view object along?

I think it's the worst part of using Django.  Having to manage a
context dictionary in every view is weak.

> Now you have to add the method *and* pass it along in the
> dictionary. Double work?

It is double the work, no doubt about it.  Not to mention on
complicated views the context dictionary gets quite long.  At that
point I usually just package everything up as a single entry.


-- 
Greg Donald

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.