Add disabled cookies as possible cause of csrf token 403 debug page

[h3]

I tried and double checked the given possibilities and ended up
finding that cookies were diabled on my phone..

Would be nice if there was a hint about this in the debug page.

-- 
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: Documentation for CBV's?

[Russell Keith-Magee]

On Mon, Dec 12, 2011 at 4:04 PM, Victor Hooi  wrote:
> Russ Magee/Preston:
>
> I don't know if I'm either qualified enough or knowledgeable enough on
> Django's core to contribute substantially to the documentation itself...lol.

Everyone has to begin somewhere, and documentation is a great place to
start. The best thing about contributing to the documentation of an
open source project is that if you don't know something, you can go
read the code until you do :-)

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: Django-nonrel patches

[Anssi Kääriäinen]

On Dec 12, 4:53 pm, Wilfred Hughes  wrote:
> > [Django] is (sort of) _emulating_ SQL cascading deletes, but it does so in 
> > a way that doesn't assume anything at all from the backend.
>
> I'm not sure this is correct. If I define the following models:

> In [1]: from vortaro.models import Person, Car
>
> In [2]: p = Person.objects.create(name='bob')
>
> In [3]: c = Car.objects.create(name='robin reliant', owner=p)

At this point you have a person, and a related car in DB.
> In [4]: p.delete()
>
> In [5]: Car.objects.all()
> Out[5]: []

Delete starts here:
>  {'sql': u'SELECT "vortaro_car"."id", "vortaro_car"."name",
> "vortaro_car"."owner_id" FROM "vortaro_car" WHERE
> "vortaro_car"."owner_id" IN (1)',
>   'time': '0.001'},

We are deleting person with id 1. Here we fetch related cars.
>  {'sql': u'DELETE FROM "vortaro_car" WHERE "id" IN (1)', 'time':
> '0.000'},

Now this is the emulated cascade. Above we found one car with id 1.
Now we are deleting it.
>  {'sql': u'DELETE FROM "vortaro_person" WHERE "id" IN (1)', 'time':
> '0.000'},

All related objects have been deleted, so now we delete the person.
>  {'sql': u'SELECT "vortaro_car"."id", "vortaro_car"."name",
> "vortaro_car"."owner_id" FROM "vortaro_car" LIMIT 21',
>   'time': '0.000'}]

Here nothing is found, as excepted.
> This isn't making a second query to deleting the Car model, it is
> depending on the database to do this.

It did make a delete to the Car model, but _before_ the person was
deleted. That is the correct order to delete the objects.
> For comparison, here's the same on App Engine:

> In [7]: c.owner

> DoesNotExist: Person matching query does not exist.

I believe AppEngine could have executed the above queries, there are
no joins. Instead it has deleted the Person, but left the related car
in the DB.

 - Anssi

-- 
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: Django-nonrel patches

[Karen Tracey]

On Mon, Dec 12, 2011 at 9:53 AM, Wilfred Hughes wrote:

> Following up on #17338 ([nonrel] supports_deleting_related_objects
> database feature flag):
>
> carljm said that:
>
> > [Django] is (sort of) _emulating_ SQL cascading deletes, but it does so
> in a way that doesn't assume anything at all from the backend.
>
> I'm not sure this is correct. If I define the following models:
>
> from django.db import models
>
> class Person(models.Model):
>name = models.CharField(max_length=100)
>
>
> class Car(models.Model):
>name = models.CharField(max_length=100)
>owner = models.ForeignKey(Person)
>
> Related objects are indeed deleted on a sqlite Django project:
>
> In [1]: from vortaro.models import Person, Car
>
> In [2]: p = Person.objects.create(name='bob')
>
> In [3]: c = Car.objects.create(name='robin reliant', owner=p)
>
> In [4]: p.delete()
>
> In [5]: Car.objects.all()
> Out[5]: []
>
> In [6]: from django.db import connection
>
> In [7]: connection.queries
> Out[7]:
> [{'sql': u'INSERT INTO "vortaro_person" ("name") VALUES (bob)',
>  'time': '0.001'},
>  {'sql': u'INSERT INTO "vortaro_car" ("name", "owner_id") VALUES
> (robin reliant, 1)',
>  'time': '0.001'},
>

This SELECT:


>  {'sql': u'SELECT "vortaro_car"."id", "vortaro_car"."name",
> "vortaro_car"."owner_id" FROM "vortaro_car" WHERE
> "vortaro_car"."owner_id" IN (1)',
>  'time': '0.001'},
>  {'sql': u'DELETE FROM "vortaro_car" WHERE "id" IN (1)', 'time':
> '0.000'},
>

And the above subsequent delete of a votaro_car are Django finding the cars
referencing the to-be-deleted Person and deleting them, before deleting the
Person, which comes next.


>  {'sql': u'DELETE FROM "vortaro_person" WHERE "id" IN (1)', 'time':
> '0.000'},
>  {'sql': u'SELECT "vortaro_car"."id", "vortaro_car"."name",
> "vortaro_car"."owner_id" FROM "vortaro_car" LIMIT 21',
>  'time': '0.000'}]
>
> This isn't making a second query to deleting the Car model, it is
> depending on the database to do this.


Django did explicitly find-and-delete the Car. It did not rely on the
underlying database to do that.


> For comparison, here's the same
> on App Engine:
>
> In [1]: from test_app.models import Person, Car
>
> In [2]: p = Person.objects.create(name='bob')
>
> In [3]: c = Car.objects.create(name='robin reliant', owner=p)
>
> In [4]: p.delete()
>
> In [5]: Car.objects.all()
> Out[5]: []
>
> In [6]: c = Car.objects.get()
>
> In [7]: c.owner
> ---
> DoesNotExist  Traceback (most recent call
> last)
> /home/wilfred/bleeding_edge/django-testapp/ f94c13ea1b0a> in ()
> > 1 c.owner
>
> /home/wilfred/bleeding_edge/django-testapp/django/db/models/fields/
> related.pyc in __get__(self, instance, instance_type)
>313 rel_obj = rel_mgr.using(db).get(**params)
>314 else:
> --> 315 rel_obj =
> QuerySet(self.field.rel.to).using(db).get(**params)
>316 setattr(instance, cache_name, rel_obj)
>317 return rel_obj
>
> /home/wilfred/bleeding_edge/django-testapp/django/db/models/query.pyc
> in get(self, *args, **kwargs)
>349 if not num:
>350 raise self.model.DoesNotExist("%s matching query
> does not exist."
> --> 351 % self.model._meta.object_name)
>352 raise self.model.MultipleObjectsReturned("get()
> returned more than one %s -- it returned %s! Lookup parameters were
> %s"
>353 % (self.model._meta.object_name, num, kwargs))
>
> DoesNotExist: Person matching query does not exist.
>
> Have I horribly misunderstood?
>
>
It seems the problem here is that Django's attempt to find the Cars
referencing the to-be-deleted person is failing here, so it did not delete
the associated Car. It would if it could find it though, really it's not
using database cascade delete for this.

Karen

-- 
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: Django-nonrel patches

[Wilfred Hughes]

Following up on #17338 ([nonrel] supports_deleting_related_objects
database feature flag):

carljm said that:

> [Django] is (sort of) _emulating_ SQL cascading deletes, but it does so in a 
> way that doesn't assume anything at all from the backend.

I'm not sure this is correct. If I define the following models:

from django.db import models

class Person(models.Model):
name = models.CharField(max_length=100)


class Car(models.Model):
name = models.CharField(max_length=100)
owner = models.ForeignKey(Person)

Related objects are indeed deleted on a sqlite Django project:

In [1]: from vortaro.models import Person, Car

In [2]: p = Person.objects.create(name='bob')

In [3]: c = Car.objects.create(name='robin reliant', owner=p)

In [4]: p.delete()

In [5]: Car.objects.all()
Out[5]: []

In [6]: from django.db import connection

In [7]: connection.queries
Out[7]:
[{'sql': u'INSERT INTO "vortaro_person" ("name") VALUES (bob)',
  'time': '0.001'},
 {'sql': u'INSERT INTO "vortaro_car" ("name", "owner_id") VALUES
(robin reliant, 1)',
  'time': '0.001'},
 {'sql': u'SELECT "vortaro_car"."id", "vortaro_car"."name",
"vortaro_car"."owner_id" FROM "vortaro_car" WHERE
"vortaro_car"."owner_id" IN (1)',
  'time': '0.001'},
 {'sql': u'DELETE FROM "vortaro_car" WHERE "id" IN (1)', 'time':
'0.000'},
 {'sql': u'DELETE FROM "vortaro_person" WHERE "id" IN (1)', 'time':
'0.000'},
 {'sql': u'SELECT "vortaro_car"."id", "vortaro_car"."name",
"vortaro_car"."owner_id" FROM "vortaro_car" LIMIT 21',
  'time': '0.000'}]

This isn't making a second query to deleting the Car model, it is
depending on the database to do this. For comparison, here's the same
on App Engine:

In [1]: from test_app.models import Person, Car

In [2]: p = Person.objects.create(name='bob')

In [3]: c = Car.objects.create(name='robin reliant', owner=p)

In [4]: p.delete()

In [5]: Car.objects.all()
Out[5]: []

In [6]: c = Car.objects.get()

In [7]: c.owner
---
DoesNotExist  Traceback (most recent call
last)
/home/wilfred/bleeding_edge/django-testapp/ in ()
> 1 c.owner

/home/wilfred/bleeding_edge/django-testapp/django/db/models/fields/
related.pyc in __get__(self, instance, instance_type)
313 rel_obj = rel_mgr.using(db).get(**params)
314 else:
--> 315 rel_obj =
QuerySet(self.field.rel.to).using(db).get(**params)
316 setattr(instance, cache_name, rel_obj)
317 return rel_obj

/home/wilfred/bleeding_edge/django-testapp/django/db/models/query.pyc
in get(self, *args, **kwargs)
349 if not num:
350 raise self.model.DoesNotExist("%s matching query
does not exist."
--> 351 % self.model._meta.object_name)
352 raise self.model.MultipleObjectsReturned("get()
returned more than one %s -- it returned %s! Lookup parameters were
%s"
353 % (self.model._meta.object_name, num, kwargs))

DoesNotExist: Person matching query does not exist.

Have I horribly misunderstood?

Wilfred

-- 
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: Python 3 port - all MySQL tests now pass on 2.6.7 and 3.2.2 with the same codebase

[Tom Evans]

On Fri, Dec 9, 2011 at 7:43 PM, Joe & Anne Tennies  wrote:
> The thing is, we aren't trying to "scientifically correct" statistics. What
> we're aiming to say is, "This is not so wildly different as to be of any
> concern." We aren't looking for minor difference, but orders of magnitude
> difference.
>
> If you are that worried about a <2% difference in speed, you probably
> shouldn't be using Python... or at least Django. You should be finding the
> parts that you can optimize for your specific application and optimizing
> those. Python 3 *IS* the future. There isn't much way around that at this
> point. I believe the general idea is to make sure the solution at this point
> does not slow everything down to the point where it would be impossible for
> someone to switch to Python 3. Don't get me wrong, I don't want to see a 2%
> increase in timing all the time, but Python 3 support is a bullet that will
> HAVE to get bitten.

Py3k is the future, changing DB adapter from a C library with a python
wrapper to a pure python adaptor should merit some performance testing
of the new adaptor, which is what I really wanted to test.

However, it is bad science (we should all consider ourselves
scientists) to do one run and say that performance hasn't changed.

Regression testing is not just about changes in test results, changes
should also not make the framework unnecessarily slow, and the only
way to determine how much effect a changeset has is to benchmark it,
and the only way to benchmark it is scientifically, using statistics
and to a high degree of confidence.

We should only care about large changes in performance, but how do you
determine if something is a large change, without statistically valid
benchmarks?

>
> Also, I am expecting I could make bigger gains by just using that pure
> Python MySQL driver and running under PyPy. If the major part of the time
> wasn't spent inside the actual database (which should be fairly obviously
> the case as switching from SQLite in memory to MySQL is a >5x increase in
> time).
>

Statistics or shut up :) Only joking :)

How the pure python mysql driver performs compared to one built around
libmysqlclient is particularly interesting. Have you actually tried
this, or are you speculating?


Ian, thanks for running those tests. Running the numbers through
ministat tells us that the patches are slightly slower (3.2% ± 2.5%,
at a 99% confidence).

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: Documentation for CBV's?

[Victor Hooi]

Russ Magee/Preston:

I don't know if I'm either qualified enough or knowledgeable enough on 
Django's core to contribute substantially to the documentation itself...lol.

However, I am happy to offer whatever I can - whether that means proofing 
drafts, contributing a beginner's viewpoint, or walking through a tutorial, 
I'm game to do that.

Preston - What do you think is the best way for others to 
collaborate/comment on your CBV docs? Should we be forking your fork on 
Github again? Or would you be amenable to using something like Google Docs 
or Wave for this?

(We'd need to convert back to RST afterwards, but it makes does make small 
simultaneous edits/comments among lots of people very easy)

https://docs.google.com/document/d/1z2zUVAo2csol9y6tUxMSoYWa65Wr9xtehRQ7GiMGyIg/edit
https://docs.google.com/document/d/18veral-ajxjMh0ZaU0wy5Sg5p9sqFMp5X3-8CuIM31A/edit

I've made a couple of small corrections to the Class Based Views doc - you 
can see them at File, See revision history, Show more detailed revisions.

Is this the sort of thing you mean?

Cheers,
Victor

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/q7Ev303BjgwJ.
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.