>
> Nope. a large OFFSET of N will read through N rows, regardless index
> coverage. see http://www.postgresql.org/docs/9.1/static/queries-limit.html
>
That's simple not true.
If you define a Order By with a well indexes query, the database will only
do a bitmap scan.
This wiki isn't well explaine
One possible way forward is to add "errors" argument to the clean()
method. Then it would be possible to use the same API everywhere by
doing errors.add_error('my_field', 'My Error message').
I don't know how strongly we feel about breakages caused by new
arguments to methods. We broke model.save(
Neither will go away, `ValidationError(dict)` is used internally to carry
errors from the model layer to the form layer, and `add_error()` is used
internally to interpret the `ValidationError` raised throughout the system;
basically any `raise ValidationError` is followed by a call to `add_error
I hope to get flake8 running on pull request builds soon. Then (unless
there are objections) I will take a look at isort and see if it'll work for
us in a similar fashion. From my perspective it would be great to get those
checks automated so it's one less thing to think about during code review
Great! Thanx
Op zaterdag 15 november 2014 18:08:34 UTC+1 schreef Ilja Maas:
>
> Investigating https://code.djangoproject.com/ticket/21163
> I came across these lines in mysql/base.py:
>
> if settings.DEBUG:
> warnings.filterwarnings("error", category=Database.Warning)
>
>
> Finding out why, t
Just to close the loop, I created a ticket and will commit shortly:
https://code.djangoproject.com/ticket/23871
On Monday, November 17, 2014 5:44:35 AM UTC-5, Florian Apolloner wrote:
>
>
>
> On Monday, November 17, 2014 11:40:15 AM UTC+1, Aymeric Augustin wrote:
>>
>> 2014-11-17 10:45 GMT+01:00
On 11/18/2014 12:34 PM, Alasdair Nicol wrote:
> On 17/11/14 16:53, Carl Meyer wrote:
>> (Personally I think it would be better to document the same technique
>> for both Model.clean() and Form.clean(), because I don't think
>> Form.add_error() is significantly easier, and it breaks the API
>> consi
2014-11-19 14:49 GMT+01:00 Schmitt, Christian :
> A sequence scan will only be made, if you query non indexed values.
>
So if you add a simple ORDER BY you will make a index scan, which is very
> fast.
>
Nope. a large OFFSET of N will read through N rows, regardless index
coverage. see http://www
A sequence scan will only be made, if you query non indexed values.
So if you add a simple ORDER BY you will make a index scan, which is very
fast.
The problem relies more on the database than on the ORM.
As already said. If you need to deal with that much queries you need to log
your SQL statement
also, the offset + limit pagination strategy of django paginator is
sub-optimal as it has N complexity: doing SELECT * FROM auth_user LIMIT 100
offset 100 causes a 10-long table scan
2014-11-19 13:56 GMT+01:00 Marco Paolini :
>
>
> 2014-11-19 13:50 GMT+01:00 Rick van Hattem :
>
>> Definit
2014-11-19 13:50 GMT+01:00 Rick van Hattem :
> Definitely agree on this, silently altering a query's limit is probably
> not the way to go. Raising an exception in case of no limit and lots of
> results could be useful.
>
> For the sake of keeping the discussion useful:
> - Let's say you have a ta
Definitely agree on this, silently altering a query's limit is probably not
the way to go. Raising an exception in case of no limit and lots of results
could be useful.
For the sake of keeping the discussion useful:
- Let's say you have a table with 50,000 items, not an insanely large
amount im
Hi Carl,
Thruthfully some part of my reason for forking was that I was running an
older version of Django which didn't have custom user models. In that case
it's a bit more difficult to override the manager and I've seen quite a few
external projects (accidently) do something like "User.objects
Hi Arun,
This group is for discussion of development of Django itself. Your
question is better suited to the 'Django users' group:
https://groups.google.com/forum/#!forum/django-users
All the best,
Peter
On 18 November 2014 15:51, Arun Marathe wrote:
>
>
>
> We have Django 1.6.
>
> For a som
Hi Arun,
usage questions should go to django-users. This mailing list is about the
development of Django itself.
Cheers,
Florian
On Tuesday, November 18, 2014 4:51:27 PM UTC+1, Arun Marathe wrote:
>
>
>
>
> We have Django 1.6.
>
> For a somewhat obscure reason, I need to stop the testserver fro
15 matches
Mail list logo
