(which is why I placed the abstract part between ()). The advantage of
having a base class is also that your editor can automatically complete the
signature if you're planning to implement it.
Would there be anything against it though? A non-abstract base class in
that case :)
~rick
request like that be acceptable?
~rick
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developer
Hi all
Could there be a consensus with
-default to ASCII
-optionally, UTF8 with normalization
-based on Claude's code
-Python 3 required so we are not distracted by compatibility issues
Cheers -- Rick
--
You received this message because you are subscribed to the Google Groups
&q
large transactions.
HTH -- Rick
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developer
Thanks. To summarize quickly, (corrections please)
2008 - Usernames in django.contrib.auth are restricted to ASCII
alphanumerics. Allowing Unicode seems fairly simple: compile the
validator's regular expression with the re.UNICODE flag.
but:
http://en.wikipedia.org/wiki/Internationalized_doma
r-content
Perl Starman has a config "--limit-request-body
<https://github.com/miyagawa/Starman/pull/75/commits/fea2647699b01fe502420b9ee3c06b4ff64a0e58>
https://github.com/miyagawa/Starman/pull/75
HTH -- Rick
On Wednesday, 9 September 2015 20:22:23 UTC-4, Tim Graham wrote:
>
>
nything in this list. Would you point me
at any relevant discussions here please?
Thanks -- Rick
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving
hy I
responded this slowly.
On Monday 15 June 2015 22:52:09 Rick van Hattem wrote:
> > On 15 June 2015 at 21:34, Florian Apolloner > wrote:
> > > On Monday, June 15, 2015 at 7:07:38 PM UTC+2, Rick van Hattem (wolph)
> > >
> > > wrote:
> > >> Wo
On 15 June 2015 at 21:34, Florian Apolloner wrote:
>
>
> On Monday, June 15, 2015 at 7:07:38 PM UTC+2, Rick van Hattem (wolph)
> wrote:
>>
>> Would anyone oppose a pull request like this?
>>
>
> Yes, it is highly backwards incompatible for not much gain, I
While I understand the rationale, it's not really possible due to the
underlying Python object:
>>> import datetime
>>> datetime.date()
Traceback (most recent call last):
File "", line 1, in
TypeError: Required argument 'year' (pos 1) not found
>>> datetime.datetime()
Traceback (most recent cal
While there are several solutions to this problem, I find myself
scaffolding the Django admin every time I create a new app/model. I even
created an app to do just that (harmless
plug: https://pypi.python.org/pypi/django-admin-generator/).
Anyhow... I've wondered for some time why Django doesn'
Thanks for the help but writing the custom database backend won't be a
problem, I've written one before :)
My goal was simply to move the Django project forward but it seems the
problems I've encountered in the field are too uncommon for most other
developers to care or understand.
Thank you all
2014, at 3:36 AM, Rick van Hattem wrote:
> > If you fetch N+1 items you know if there are over N items in your list.
>
> Let's stop there. Unfortunately, because of the way libpq works, just
> sending the query and checking the result set size won't solve your
> p
rotect
servers from dying without any traceable cause as the resource starvation
can kill the machine without ever showing anything useful in the logs.
On 24 November 2014 at 12:16, Christophe Pettus wrote:
>
> On Nov 24, 2014, at 1:08 AM, Rick van Hattem wrote:
>
> > Indeed,
On 23 November 2014 at 22:57, Christophe Pettus wrote:
>
> On Nov 23, 2014, at 1:53 PM, Rick van Hattem wrote:
>
> > Very true, that's a fair point. That's why I'm opting for a configurable
> option. Patching this within Django has saved me in quite a few
Django's ORM is just the wrong level in the software stack for these
> limits, since there are hundreds of other ways to kill the performance of a
> server, and the number of results in a queryset is a poor indicator of
> performance issues.
>
> On Sunday, 23 November 2014
On 23 Nov 2014 22:13, "Christophe Pettus" wrote:
>
>
> On Nov 23, 2014, at 1:07 PM, Rick van Hattem wrote:
>
> > > Not really, cause psycopg already fetched everything.
> >
> > Not if Django limits it by default :)
>
> Unfortunately, that's
Hi Florian,
On 23 Nov 2014 16:22, "Florian Apolloner" wrote:
>
> Hi Rick,
>
>
> On Sunday, November 23, 2014 1:11:13 PM UTC+1, Rick van Hattem wrote:
>>
>> If/when an unsliced queryset were to reach a certain limit (say, 10,000,
but configurable) the syst
cursor = connection.connection.cursor(name='hello')
> cursor.execute('BIG QUERYSET SQL')
> for row in cursor: # fetches rows in cursor.itersize chunks
> pass
>
> I use this in a few scripts that iterate over 10GB of table data. But a
> way to map
On Thursday, November 20, 2014 8:31:06 AM UTC+1, Christian Schmitt wrote:
>
> 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
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
19, 2014 3:52:52 AM UTC+1, Carl Meyer wrote:
>
> Hi Rick,
>
> On 11/18/2014 11:59 AM, Rick van Hattem wrote:
> [snip]
> > In all but the most basic Django projects I've seen problems like these.
> > Sane defaults won't hurt anyone and solves issues for peop
ngs by yourself.
>
> If your patches are enough than live with it, but I don't see a reason for
> optimizing django against big tables.
>
>
>
> 2014-11-18 19:27 GMT+01:00 Rick van Hattem :
>
>> That certainly solves one part of the problem. After that I would
laude Paroz wrote:
> On Tuesday, November 18, 2014 1:58:00 PM UTC+1, Rick van Hattem wrote:
>>
>> Hi guys,
>>
>> As it is right now Django has the tendency to kill either your browser
>> (if you're lucky) or the entire application server when confronted with
esultset size.
>
> I don't think Django should automatically limit these queries.
>
> Regards,
> Michael Manfre
>
> On Tue, Nov 18, 2014 at 7:58 AM, Rick van Hattem > wrote:
>
>> Hi guys,
>>
>> As it is right now Django has the tendency to kill eit
Hi guys,
As it is right now Django has the tendency to kill either your browser (if
you're lucky) or the entire application server when confronted with a large
database. For example, the admin always does counts for pagination and a
count over a table with many rows (say, in the order of 100M)
king on a
revision that's about a year old) I will write a patch for this problem.
Patching the old release and merging it with the current changes looks like
it is going to be quite a tedious process.
~Rick
signature.asc
Description: This is a digitally signed message part.
you can break the entire debugging system by simply raising an
exception like this:
class MyException(Exception):
source = 'Breaking the Django template debugger'
~Rick
signature.asc
Description: This is a digitally signed message part.
BTW, generally I like this idea... :)
On Mon, Dec 7, 2009 at 10:23 PM, Rick Yazwinski
wrote:
> I think that this may be too simplified:
> protocol = getattr(settings, "PROTOCOL", "http")
> domain = Site.objects.get_current().domain
>
I think that this may be too simplified:
protocol = getattr(settings, "PROTOCOL", "http")
domain = Site.objects.get_current().domain
port = getattr(settings, "PORT", "")
Many sites put load balancers and https hardward acceleration in front
of their web interfaces. This wo
e: No module named _sqlite3
I tried appending the path to sqlite3 to my PYTHONPATH but that hasn't
worked so far.
Any ideas about what is wrong with my installation?
Thanks in advance.
Rick
--~--~-~--~~~---~--~~
You received this message because you are subscri
Any chance any of the developers of this db backend are on this list ?
If so please respond, I would like to help you test and have run into
some issues with the code on
http://code.google.com/p/django-pyodbc/
Thanks,
Rick
--~--~-~--~~~---~--~~
You received this
32 matches
Mail list logo
