The accepted answer is spot on about the regex, but since we're discussing optimization, I thought I should note that the code for checking whether a project exists could be modified to generate a much quicker query, especially in other contexts where you could be counting millions of rows needlessly. Call this 'best practices' advice, if you will.
p = Project.objects.filter(projectName__exact = aProjectName).count() if p > 0:
could instead be
if Project.objects.filter(project_name__iexact=aProjectName).exists():
for two reasons.
First, you're not using p
for anything so there's no need to store it as a variable as it increases readability and p
is an obscure variable name and the best code is no code at all.
Secondly, by This way we only ask for a single row instead of saving the results to the queryset cache. Please see the official Queryset API docs, a related question on Stack Overflow and the discussion about the latter on the django-developers group.
Additionally, it is customary in python (and Django, naturally) to name your fields lower_cased_separated_by_underscores. Please see more about this on the Python Style Guide (PEP 8).
----------------------------------------------------------------------
Indeed it was. As Alisdair posted, simplify the regex and validate elsewhere. Thanks.
On Wednesday, January 30, 2013 11:26:51 AM UTC-6, fgallina wrote:2013/1/30 Shawn H <shawn....@gmail.com>:> I posted this question yesterdat at stack overflow, but I'm wondering if
> this is a bug. I have a url that accepts one text parameter, allows spaces,
> and calls a very simple view that checks if there are objects with a project
> name that matches the text parameter value. The view returns a simple json
> string indicating whether there's a project with that name already in the
> database. It works great, repeatedly, with short parameter values. It
> locks up python on certain long string values. I've tested up to 50
> characters, and just length doesn't trigger it. What does seem to
> repeatedly trigger it are long strings with multiple spaces. I've tested my
> url regex matching and those long strings match just fine; my concern is
> that for some reason inside the view that long string is causing problems.
> I'm using Django 1.4 with the built in webserver for testing. Any help that
> can be provided will be greatly appreciated.
>
I have a strong feeling it is related on how your regexp matches the
passed string, I don't know why in the world you would sanitize the
project's name directly in the url and not the view, in any case if
the user happen to enter garbage then filter will not find anything,
right? Also this seems a job for a GET parameter rather than a view
param, but YMMV.
Regards,
--
Fabián E. Gallina
http://www.from-the-cloud.com--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
No comments:
Post a Comment