Re: Fixtures won't load twice in same testcase

2016-05-06 Thread Alasdair Nicol
Hi Rich,

Regarding a couple of things you mentioned on Django-developers:

On Thursday, 5 May 2016 19:20:16 UTC+1, Rich Rauenzahn wrote:
>
>
> Thanks, Tim.
>
> Unfortunately I can't move past Django 1.7 yet -- dependencies.  I've been 
> marching my way up one revision at a time hopefully up to 1.9 as a way to 
> keep the scope of what breaks under control as I move through each major 
> revision and stabilize my project.  Then I attack replacing dependencies.
>
> I really think I've found a bug here ... which I hope to suggest a patch 
> for and submit, hence the post to the developers channel, but I can go back 
> to the users group for now... My recent experience with that list doesn't 
> bode well, however, and I don't have high hopes with anyone there able to 
> respond at the internals level I may need to track down the issue.  I've 
> almost rewritten my tests to just load raw sql, but if there is a bug here 
> I'd like to help find it rather than work around/ignore it.
>

Fixture loading was changed in Django 1.8 [1], so even if you have found a 
bug in Django 1.7, there's a good chance that behaviour will be different 
in Django 1.8 and later.


> But In this particular run I'm currently tracing, rich is already in the 
> db (as the only entry) as pk=5 (via fixture loading process).   For one, 
> this tells me the sequence generators aren't always resetting between 
> fixture loads/tests.
>
>  
Sequences *are not* reset between test cases by default [2]. Perhaps you 
need to change your code so that it doesn't assume that the user has pk=1, 
or set reset_sequences = True.

It's difficult to offer any more advice, because you haven't posted any 
code that can reproduce the problem. It doesn't need to be the actual code, 
in fact the simpler the example is the better.

Cheers,
Alasdair

[1]: https://docs.djangoproject.com/en/1.9/releases/1.8/#testcase-data-setup
[2]: 
https://docs.djangoproject.com/en/1.9/topics/testing/advanced/#django.test.TransactionTestCase.reset_sequences

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/d877ef6b-75d2-4197-85ab-9c0901e7ad95%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: django1.7, python3.4 and MySQL

2015-05-20 Thread Alasdair Nicol

Hi eduardo,

Have you tried the following?

pip install mysqlclient

Usually, you should use the package name, you don't need to specify the 
specific wheel you want to install.


Cheers,
Alasdair

On 20/05/15 16:03, eduardo.canaljun...@gmail.com wrote:

Hi, sorry but I tryed to install
mysqlclient-1.3.6-cp34-none-win_amd64.whl using pip (pip install
mysqlclient-1.3.6-cp34-none-win_amd64.whl) and I can't, the pip launch
de exceptio UnsupportedWheel, I have installed Python3.4.2 in Windows8.1
and I don't know if the error happens by a version problem. I really
need some help. Thanks
ERROR LOG REPORT:
C:\Python34\Scripts\pip run on 05/20/15 10:50:28
mysqlclient-1.3.6-cp34-none-win_amd64.whl is not a supported wheel on
this platform.
Exception information:
Traceback (most recent call last):
   File "C:\Python34\lib\site-packages\pip\basecommand.py", line 122, in
main
 status = self.run(options, args)
   File "C:\Python34\lib\site-packages\pip\commands\install.py", line
257, in run
 InstallRequirement.from_line(name, None))
   File "C:\Python34\lib\site-packages\pip\req.py", line 167, in from_line
 raise UnsupportedWheel("%s is not a supported wheel on this
platform." % wheel.filename)
pip.exceptions.UnsupportedWheel:
mysqlclient-1.3.6-cp34-none-win_amd64.whl is not a supported wheel on
this platform.



--
Alasdair Nicol
Developer, MEMSET

mail: alasd...@memset.com
 web: http://www.memset.com/

Memset Ltd., registration number 4504980.
Building 87, Dunsfold Park, Stovolds Hill, Cranleigh, Surrey, GU6 8TB, UK

--
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+unsubscr...@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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/555CB581.50005%40memset.com.
For more options, visit https://groups.google.com/d/optout.


Re: Django 1.8 tutorial-Chapter4: ValueError at /polls/1/vote/

2015-05-14 Thread Alasdair Nicol

On 14/05/15 02:50, charito.romeo wrote:

|
 
|


The problem is that there is a new line in the middle of

"{{ choice.id }}".

Change it to:

value="{{ choice.id }}"/>


Cheers,
Alasdair

--
Alasdair Nicol
Developer, MEMSET

mail: alasd...@memset.com
 web: http://www.memset.com/

Memset Ltd., registration number 4504980.
Building 87, Dunsfold Park, Stovolds Hill, Cranleigh, Surrey, GU6 8TB, UK

--
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+unsubscr...@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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/55548D93.3000701%40memset.com.
For more options, visit https://groups.google.com/d/optout.


Re: Django 1.8 ImportError: No module named formtools

2015-03-12 Thread Alasdair Nicol

On 11/03/15 14:22, Neto wrote:

Hi Simon,

pip install django-formtools doesn't work.

Could not find any downloads that satisfy the requirement django-formtools



It looks like it hasn't been django-formtools hasn't been released on 
PyPi yet. There's an issue [1] on the github repository to make a PyPi 
release.


Django 1.8 is in beta at the moment, hopefully django-formtools will be 
on PyPi by the time Django 1.8 is released. In the meantime, you can 
install django-formtools from github with:


pip install git+ssh://g...@github.com/django/django-formtools

Cheers,
Alasdair

[1]: https://github.com/django/django-formtools/issues/5


Em quarta-feira, 11 de março de 2015 03:12:06 UTC-3, Simon Charette
escreveu:

Hi Neto,

Here's an excerpt from the Django 1.8 release note

<https://docs.djangoproject.com/en/dev/releases/1.8/#removal-of-django-contrib-formtools>:

The formtools contrib app has been moved into a separate
package. *django.contrib.formtools* itself has been removed. The
docs provide migration instructions

<https://docs.djangoproject.com/en/dev/ref/contrib/formtools/#formtools-how-to-migrate>.

The new package is available on Github
<https://github.com/django/django-formtools/> and on PyPI.


TLDR; pip install django-formtoolsand replace all your references to
*django.contrib.formtools* to *formtools*.

Simon

Le mercredi 11 mars 2015 00:33:29 UTC-4, Neto a écrit :

I'm trying to use form wizard but when I put
'django.contrib.formtools', in INSTALLED_APPS appear on my
terminal 'ImportError: No module named formtools'

--
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+unsubscr...@googlegroups.com
<mailto:django-users+unsubscr...@googlegroups.com>.
To post to this group, send email to django-users@googlegroups.com
<mailto:django-users@googlegroups.com>.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/4bc1d119-292b-4514-bce3-b2a0e9176e7e%40googlegroups.com
<https://groups.google.com/d/msgid/django-users/4bc1d119-292b-4514-bce3-b2a0e9176e7e%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.



--
Alasdair Nicol
Developer, MEMSET

mail: alasd...@memset.com
 web: http://www.memset.com/

Memset Ltd., registration number 4504980.
Building 87, Dunsfold Park, Stovolds Hill, Cranleigh, Surrey, GU6 8TB, UK

--
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+unsubscr...@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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/55005756.50306%40memset.com.
For more options, visit https://groups.google.com/d/optout.


Re: TemplateSyntaxError with {% cycle "Hello, how are you?" "Fine!" %}

2015-03-06 Thread Alasdair Nicol

On 05/03/15 17:23, Carsten Fuchs wrote:

If you use single quotes and render the template, it outputs 'Hello',
not 'Hello, how are you?' as expected.


As expected? Why please? Docs say that with single or double quotes, the
values are treated as string literals.


Sorry, I wasn't clear. By 'as expected', I meant that you want the cycle 
tag to return "Hello, how are you". Switching to single quotes isn't a 
fix, because it only returns 'Hello'.


Cheers,
Alasdair


--
Alasdair Nicol
Developer, MEMSET

mail: alasd...@memset.com
 web: http://www.memset.com/

Memset Ltd., registration number 4504980.
Building 87, Dunsfold Park, Stovolds Hill, Cranleigh, Surrey, GU6 8TB, UK

--
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+unsubscr...@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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/54F97C30.5050303%40memset.com.
For more options, visit https://groups.google.com/d/optout.


Re: TemplateSyntaxError with {% cycle "Hello, how are you?" "Fine!" %}

2015-03-05 Thread Alasdair Nicol

Hi Carsten, Vijay

On 05/03/15 16:24, Carsten Fuchs wrote:
> Dear Django fellows,
>
> using Django 1.7.5, I have a problem with commas in string literals in
> the cycle tag, e.g. with
>
>  {% cycle "Hello, how are you?" "Fine!" %}.

I can reproduce the problem with your sample code.

I think the reason is that the cycle tag supports an older syntax for 
backwards compatibility reasons.


{% cycle row1,row2,row3 %}

It looks like this prevents you from using commas in strings when using 
the new syntax.


> This happens with or without {% load cycle from future %}

The future version of the cycle tag applies HTML escaping to its 
variables. So using it or not using it shouldn't have any affect on your 
issue.


A work around would be to assign "Hello, how are you" to a variable.

{% with hello="Hello, how are you?"
{% cycle hello "Fine!" %}.
{% endwith %}

On 05/03/15 16:48, Vijay Khemlani wrote:
> Changing the double quotes for single quotes seems to do the trick, 
but I don't know why it works


If you use single quotes and render the template, it outputs 'Hello', 
not 'Hello, how are you?' as expected.


Cheers,
Alasdair

[1] https://docs.djangoproject.com/en/1.7/ref/templates/builtins/#cycle

--
Alasdair Nicol
Developer, MEMSET

mail: alasd...@memset.com
 web: http://www.memset.com/

Memset Ltd., registration number 4504980.
Building 87, Dunsfold Park, Stovolds Hill, Cranleigh, Surrey, GU6 8TB, UK

--
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+unsubscr...@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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/54F889F2.9040107%40memset.com.
For more options, visit https://groups.google.com/d/optout.


Re: TemplateSyntaxError with {% cycle "Hello, how are you?" "Fine!" %}

2015-03-05 Thread Alasdair Nicol

On 05/03/15 16:53, Alasdair Nicol wrote:

{% with hello="Hello, how are you?"
{% cycle hello "Fine!" %}.
{% endwith %}


Oops, that should have read:

{% with hello="Hello, how are you?" %}
{% cycle hello "Fine!" %}.
{% endwith %}

--
Alasdair Nicol
Developer, MEMSET

mail: alasd...@memset.com
 web: http://www.memset.com/

Memset Ltd., registration number 4504980.
Building 87, Dunsfold Park, Stovolds Hill, Cranleigh, Surrey, GU6 8TB, UK

--
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+unsubscr...@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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/54F88A38.6020906%40memset.com.
For more options, visit https://groups.google.com/d/optout.


Re: malicious requests?

2014-12-22 Thread Alasdair Nicol

Hi Alex,

There is no security implication adding 'example.com.' (with trailing 
dot) to your ALLOWED_HOSTS setting. There is some more information in 
the ALLOWED_HOSTS setting docs.


From https://docs.djangoproject.com/en/1.7/ref/settings/#allowed-hosts


In previous [<= 1.6.X] versions of Django, if you wanted to also

> allow the fully qualified domain name (FQDN), which some browsers

can send inthe Host header, you had to explicitly add another

> ALLOWED_HOSTS entry that included a trailing period.

> In Django 1.7, the trailing dot is stripped when performing host
> validation, thus an entry with a trailing dot isn’t required.

cheers,
Alasdair



On 22/12/14 12:05, Alex Haylock wrote:

Thanks Markus.

So, as per the RFC, are 'example.com' and 'example.com.' considered to
be the same domain, or two separate domains?

Are there any security implications if I add 'example.com.' to
ALLOWED_HOSTS to cater for these requests?

Thanks,

Alex.

On 22/12/14 11:52, Markus Holtermann wrote:

Hey Alex,

a trailing . in the host header is valid per RFC 3986:
http://tools.ietf.org/html/rfc3986#section-3.2.2:

 The rightmost domain label of a fully qualified domain name in DNS
 may be followed by a single "."


/Markus

On Monday, December 22, 2014 12:44:25 PM UTC+1, Alex Haylock wrote:

 Are there any known attack vectors that involve appending a period/
 full-stop to a sites domain name?

 My Django application throws a handful of errors in production every
 day:

 ERROR: Invalid HTTP_HOST header: 'www.example.com.'. You may need to
 add
 u'www.example.com <http://www.example.com>.' to ALLOWED_HOSTS.

 (note the trailing period)

 Is this malicious behaviour, or just users mistyping the URL?

 Also, browsers are clearly treating the final '.' as part of the path
 (as these requests are reaching my application), but Django is treating
 the '.' as part of the hostname. Which is right?

 --
 Regards,


 Alex






--
Alasdair Nicol
Developer, MEMSET

mail: alasd...@memset.com
 web: http://www.memset.com/

Memset Ltd., registration number 4504980.
Building 87, Dunsfold Park, Stovolds Hill, Cranleigh, Surrey, GU6 8TB, UK

--
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+unsubscr...@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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/54982391.6050604%40memset.com.
For more options, visit https://groups.google.com/d/optout.


Re: Replacing usage of form._errors in Django 1.7

2014-11-20 Thread Alasdair Nicol

Hi Collin,

On 17/11/14 21:19, Collin Anderson wrote:

Hi Alasdair,

I'm upgrading to Django 1.7, and updating my forms to use the new
form.add_errors() method.

I have one remaining pattern which uses form._errors.

class MyForm(forms.Form):
  ...
  def clean():
 cleaned_data = super(MyForm, self).clean()
 if not self._errors:
 do_something()

I only want to call do_something() if no errors have been found during
the validation so far. I'd rather not use self._errors, since it is now
a private API according to the release notes [1]. What's the
recommended
way to replace self._errors here?

Is it ok to use self.errors instead? Looking at the source code [2],
errors is a property, not an attribute. By the time the clean() method
is called, self._errors should have been created, so I think that
accessing self.errors should be safe.


The doc says it's ok.
"Since the field validation methods have been run by the time clean() is
called, you also have access to the form’s errors attribute which
contains all the errors raised by cleaning of individual fields."

https://docs.djangoproject.com/en/dev/ref/forms/validation/#form-subclasses-and-modifying-field-errors



Thanks for your reply, and your link to the docs. I can go ahead and 
replace my occurrences of self._errors with self.errors with confidence :)


Cheers,
Alasdair

--
Alasdair Nicol
Developer, MEMSET

mail: alasd...@memset.com
 web: http://www.memset.com/

Memset Ltd., registration number 4504980.
Building 87, Dunsfold Park, Stovolds Hill, Cranleigh, Surrey, GU6 8TB, UK

--
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+unsubscr...@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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/546E0B87.7050001%40memset.com.
For more options, visit https://groups.google.com/d/optout.


Replacing usage of form._errors in Django 1.7

2014-11-14 Thread Alasdair Nicol

Hi,

I'm upgrading to Django 1.7, and updating my forms to use the new 
form.add_errors() method.


I have one remaining pattern which uses form._errors.

class MyForm(forms.Form):
...
def clean():
   cleaned_data = super(MyForm, self).clean()
   if not self._errors:
   do_something()

I only want to call do_something() if no errors have been found during 
the validation so far. I'd rather not use self._errors, since it is now 
a private API according to the release notes [1]. What's the recommended 
way to replace self._errors here?


Is it ok to use self.errors instead? Looking at the source code [2], 
errors is a property, not an attribute. By the time the clean() method 
is called, self._errors should have been created, so I think that 
accessing self.errors should be safe.


cheers,
Alasdair

[1]: https://docs.djangoproject.com/en/dev/releases/1.7/#form-add-error
[2]: https://github.com/django/django/blob/1.7.1/django/forms/forms.py#L150

--
Alasdair Nicol
Developer, MEMSET

mail: alasd...@memset.com
 web: http://www.memset.com/

Memset Ltd., registration number 4504980.
Building 87, Dunsfold Park, Stovolds Hill, Cranleigh, Surrey, GU6 8TB, UK

--
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+unsubscr...@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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/5465E3AC.2040804%40memset.com.
For more options, visit https://groups.google.com/d/optout.


Re: Did Ubuntu 14.04 or Linux Mint 17 break your Django project files?

2014-07-16 Thread Alasdair Nicol

Hi,

On 16/07/14 21:53, Pepsodent Cola wrote:

Hi,
I have been learning and developing my first Django project in Linux
Mint 14 for about 2 years.  This month I moved my Django project files
to Linux Mint 17.
When I run my unit tests then I get this error, which I don't remember
having when I was testing code in Linux Mint 14.

*IntegrityError: NOT NULL constraint failed:*
userprofile_userprofile.likes_cheese


NOT NULL constraint failed
I try to change the old code from this.

class UserProfile(models.Model):
 user = models.OneToOneField(User)
 likes_cheese = models.*BooleanField()*
 favourite_hamster_name = models.CharField(max_length=50)



It sounds looks like your operating system upgrade has upgraded Django 
to 1.6. In Django 1.6 you need to explicitly set default=False on your 
boolean fields, otherwise they default to None


>  likes_cheese = models.BooleanField(default=False)

For more info see the release notes [1]. It would be worth going through 
them to see if there are any other changes you should or need to make.


[1]: 
https://docs.djangoproject.com/en/dev/releases/1.6/#booleanfield-no-longer-defaults-to-false


Cheers,
Alasdair

--
Alasdair Nicol
Developer, MEMSET

mail: alasd...@memset.com
 web: http://www.memset.com/

Memset Ltd., registration number 4504980.
Building 87, Dunsfold Park, Stovolds Hill, Cranleigh, Surrey, GU6 8TB, UK

--
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+unsubscr...@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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/53C6EF99.5050205%40memset.com.
For more options, visit https://groups.google.com/d/optout.


Re: Writing your first Django app, part 1 (1.6)

2013-12-11 Thread Alasdair Nicol

Hi,

The Django tutorial has changed between 1.6 and the current development 
version. Because your error references the Choices.question field, it 
sounds as if you may have been following the development version in places.


Make sure that you follow the Django 1.6 tutorial throughout. If you 
retry and follow the instructions, it should work.


You can select the version of the tutorial using the selector in the 
bottom-right corner of the screen.


Cheers,
Alasdair

On 10/12/13 22:19, Suhendri wrote:

Hi,

I'm new in Django, I'm excited with Django so I have to following the
existing tutorial to knew how to create a program with Django.

I started with tutorial 1, Writing your first Django app, part1. I used
Django 1.6 and SQLite


I followed the instructions from the starting of the tutorial, until the
line of *# Create three choices* I got an error.

When I typed p.choice_set.create(choice_text='Not much', votes=0), I got
an error:
*AttributeError: Traceback (most recent call last):*
*...*
*AttributeError: 'Choice' object has no attribute 'question'*

I followed the tutorial exactly as it shown on web, but I got an error
on that line. Did I missed something in the tutorial ?

Could you help me, to solve this problem so i can continue learn the
tutorial.



--
Alasdair Nicol
Developer, MEMSET

mail: alasd...@memset.com
 web: http://www.memset.com/

Memset Ltd., registration number 4504980.
Building 87, Dunsfold Park, Stovolds Hill, Cranleigh, Surrey, GU6 8TB, UK

--
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+unsubscr...@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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/52A839AB.1070607%40memset.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: Long url parameter in GET request locks python

2013-01-30 Thread Alasdair Nicol

On 30/01/13 16:38, Shawn H wrote:
I posted this question yesterdat at stack overflow 
<http://stackoverflow.com/questions/14589244/why-would-django-get-request-with-long-url-lock-python>, 
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. --



Hi Shawn,

I've answered your question on Stack Overflow, but I'll post it here as 
well:


Since you are going to check whether `aProjectName` already exists in 
the database, there's no need for you to make the regex so complicated.


I suggest you simplify the regex to

url(r'^chargeback/checkDuplicateProject/(?P[\w+\s-]*)/$', 
'chargeback.views.isProjectDuplicate'),


For a further explanation, see the question "url regex keeps django 
busy/crashing" [1] from the django-users group.


[1]: https://groups.google.com/d/msg/django-users/Bxq9i0mttSc/DEz7S7M8lxAJ

Cheers,
Alasdair

--
Alasdair Nicol
Developer, MEMSET

mail: alasd...@memset.com
 web: http://www.memset.com/

Memset Ltd., registration number 4504980. 25 Frederick Sanger Road, Guildford, 
Surrey, GU2 7YD, UK.

--
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+unsubscr...@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.




Re: A question about Model.full_clean

2012-06-01 Thread Alasdair Nicol

On 01/06/12 14:47, David Markey wrote:

Hi All,

Say I have this model

class TestModel(models.Model):
my_test = models.CharField(max_length=512, blank=True)

And I try this:

In [1]: from core.base.models import TestModel

In [2]: test_model = TestModel()

In [3]: test_model.my_test =*""*

In [4]: test_model.full_clean()

In [5]: test_model.save()

*Ok cool, this is expected.*
*
*
*How about:*


In [6]: test_model2 = TestModel()

In [7]: test_model2.my_test =*None*

In [8]: test_model2.full_clean()

In [9]: test_model2.save()

##*IntegrityError raised*

Is there a way for full_clean() to catch that the "my_test" field is 
Null when it shouldn't be, when blank=True?


If I have blank=False, it wont validate when my_test="".




I think the behaviour is explained by the clean_fields method called by 
full_clean:



for f in self._meta.fields:
if f.name in exclude:
continue
*# Skip validation for empty fields with blank=True. The 
developer

# is responsible for making sure they have a valid value.
*raw_value = getattr(self, f.attname)
if f.blank and raw_value in validators.EMPTY_VALUES:
continue


https://github.com/django/django/blob/master/django/db/models/base.py#L851

I can't think of a way for you to avoid checking for whether 
test_model2.my_test is None. Can you change the code that is assigning 
test_model2.my_test = None? The default value for the CharField is the 
empty string, which as you show in your first example, doesn't cause a 
problem.


Cheers,
Alasdair

--
Alasdair Nicol
Developer, MEMSET

mail: alasd...@memset.com
 web: http://www.memset.com/

Memset Ltd., registration number 4504980. 25 Frederick Sanger Road, Guildford, 
Surrey, GU2 7YD, UK.

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



Re: Possible bug in the Django documentation

2012-05-14 Thread Alasdair Nicol

Hi Joseph,

On 14/05/12 14:26, Joseph Mornin wrote:

Hi,

I noticed a possible bug in the Django documentation. The
authentication docs (at https://docs.djangoproject.com/en/dev/topics/auth/)
include this sample code for registration/login.html: http://dpaste.com/747993/

Running this code gives me this error:

###
TemplateSyntaxError at /login

Caught NoReverseMatch while rendering: Reverse for
''django.contrib.auth.views.login'' with arguments '()' and keyword
arguments '{}' not found.
###

I was able to fix this by removing the quotes around the url parameter
on line 9 (with help from this StackOverflow question:
http://stackoverflow.com/questions/4578685/noreversematch-while-rendering-reverse-for-django-contrib-auth-views-login).

Hope this is useful.

Cheers,
J.

In earlier versions of Django, the url tag did not use quotes. Starting 
in Django 1.3, this was gradually changed so that the url tag was 
consistent with other tags. The change is described in the release notes 
for Django 1.3 [1]


The url you link to is for the development version of Django. If you 
look at the same page for Django 1.4 [2], you'll see that the template 
includes the following statement.


{%  load  url  from  future  %}

If you don't include this, then the alternative is to remove the quotes, 
as you found.


Hope that explains things.

Cheers,
Alasdair


https://docs.djangoproject.com/en/dev/releases/1.3/#changes-to-url-and-ssi
https://docs.djangoproject.com/en/1.4/topics/auth/


--
Alasdair Nicol
Developer, MEMSET

mail: alasd...@memset.com
 web: http://www.memset.com/

Memset Ltd., registration number 4504980. 25 Frederick Sanger Road, Guildford, 
Surrey, GU2 7YD, UK.

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



Re: Problems with {% url %} in templates

2012-03-29 Thread Alasdair Nicol

Hi Jamie,

On 29/03/12 20:49, Jamie Lawrence wrote:

I'm very confused… this has worked fine in the past. Django 1.3.1

In myproject/urls.py:

urlpatterns = patterns('',
 (r'^d/events/(.*)$', include('myproject.events.urls')),
[…]
Don't include the (.*)$ in the regex for the include. The documented 
pattern [1] for the include is


(r'^d/events/', include('myproject.events.urls')),

Regards,
Alasdair

[1]: 
https://docs.djangoproject.com/en/dev/topics/http/urls/#including-other-urlconfs


--
Alasdair Nicol
Developer, MEMSET

mail: alasd...@memset.com
 web: http://www.memset.com/

Memset Ltd., registration number 4504980. 25 Frederick Sanger Road, Guildford, 
Surrey, GU2 7YD, UK.

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



Re: Trouble setting up website with mysql as backend

2012-03-17 Thread Alasdair Nicol

On 17/03/12 20:49, Swaroop Shankar V wrote:

Hello All,
I was developing a website and the development was all done using 
sqlite database. Now the development is almost complete so i need to 
test the site using mysql. When i did a syncdb on a fresh database i 
got the following error:


Traceback (most recent call last):
  File "./manage.py", line 19, in 
execute_manager(settings)
  File 
"/usr/local/lib/python2.7/site-packages/django/core/management/__init__.py", 
line 438, in execute_manager

utility.execute()

  File 
"/usr/local/lib/python2.7/site-packages/django/contrib/auth/management/__init__.py", 
line 51, in create_permissions

content_type=ctype

  File "/usr/lib64/python2.7/site-packages/MySQLdb/cursors.py", line 
92, in _warning_check

warn(w[-1], self.Warning, 3)
_mysql_exceptions.Warning: Data truncated for column 'name' at row 1

When you run syncdb for the django auth app, it creates permissions for 
your models [1]. It looks like it's trying to insert a permission with a 
name longer than 50 characters, so it's getting truncated. Perhaps you 
have:


 * defined a custom permission with a really long name, or
 * defined a model with a really long name so that "Can view " 
is longer than 50 characters.


Regards,
Alasdair Nicol

[1]: https://docs.djangoproject.com/en/dev/topics/auth/#default-permissions

--
Alasdair Nicol
Developer, MEMSET

mail: alasd...@memset.com
 web: http://www.memset.com/

Memset Ltd., registration number 4504980. 25 Frederick Sanger Road, Guildford, 
Surrey, GU2 7YD, UK.

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



Re: Help on forms.py

2012-02-16 Thread Alasdair Nicol

Hi Stanwin,

On 16/02/12 17:43, Stanwin Siow wrote:

Hello,

I'm trying to modify the default registration forms.py by adding in 
more fields.


Currently it's like that:

=
*keyword_info = {*
*"queryset" : Keyword.objects.all(),*
*}*

class RegistrationForm(forms.Form):

*keywords = forms.ChoiceField(choices=keyword_info)*
*label=_(u'keyword'))*


You're using a ChoiceField, which requires a list of 2-tuples, for example:

   choices = [('keyword1', 'keyword1'), ('keyword1', 'keyword1')]

What you probably want is a ModelChoiceField [1], which takes a queryset 
argument.


keywords = forms.ModelChoiceField(queryset=Keyword.objects.all())

[1]: 
https://docs.djangoproject.com/en/dev/ref/forms/fields/#modelchoicefield


cheers,

Alasdair

--
Alasdair Nicol
Developer, MEMSET

mail: alasd...@memset.com
 web: http://www.memset.com/

Memset Ltd., registration number 4504980. 25 Frederick Sanger Road, Guildford, 
Surrey, GU2 7YD, UK.

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



Re: Model.delete() was not called.

2012-02-16 Thread Alasdair Nicol

Hi,

On 16/02/12 10:53, SomeoneToIgnore wrote:

Hello. I'm using Django 1.3.1.

I've got some strange behaviour while deleting an object in admin
panel.

Here's the code from models.py:

class Poll(models.Model):
 question = models.CharField(max_length=200)
 pub_date = models.DateTimeField('date published')

 def was_published_today(self):
 return self.pub_date.date() == datetime.date.today()
 was_published_today.short_description = 'Published today?'

 def __unicode__(self):
 return self.question

 def delete(self, using=None):
 print "Deleted"
 super(Poll, self).delete(using)

It is just the code from django tutorial with delete() method
overriden.

There was an issue:
https://code.djangoproject.com/ticket/11022

If I open the object's properties page and delete an object using
Delete button on that page everything works fine and message displays
in the console.

But if I check the object's checkoxes (insted of opening their
property list pages), select "Delete selected polls" action and press
the Go button, the Delete multiple objects page opens.
Then I press "Yes, I'm sure button" and objects are successfully
deleted.

But their delete() method are not triggered so i don't get the message
"Deleted" in the console.
It does not matter if I choose one or multiply objects - the message
still does not appear in the console.

Should I consider this behaviour as a bug or I am doing something
wrong?



The delete select action uses the queryset's delete method [1], which 
means the model's delete method is not called.


It's not a bug, the behaviour is documented on the admin actions page. [2]

Cheers,
Alasdair

[1]: 
https://docs.djangoproject.com/en/dev/topics/db/queries/#deleting-objects
[2]: 
https://docs.djangoproject.com/en/dev/ref/contrib/admin/actions/#admin-actions


--
Alasdair Nicol
Developer, MEMSET

mail: alasd...@memset.com
 web: http://www.memset.com/

Memset Ltd., registration number 4504980. 25 Frederick Sanger Road, Guildford, 
Surrey, GU2 7YD, UK.

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



Re: MySQL limit sub-query problem

2012-01-26 Thread Alasdair Nicol

Hi RJ,

On 26/01/12 20:10, rahul jain wrote:

All,

I have a query. Its working fine on sqlite server but not working fine
on mysql server.

This is the error message on mysql server:  "This version of MySQL
doesn't yet support 'LIMIT&  IN/ALL/ANY/SOME subquery"

This is the query:

inner_q = obj_unassigned.values_list('pk', flat=True)[:diff]
total_objects = (obj_assigned | obj_class.objects.filter(pk__in=inner_q))

Any help appreciated on how to fix this.

Thanks.

RJ



You can prevent the error by using `list()` to fetch the inner queryset 
in a separate query:


total_objects = (obj_assigned | obj_class.objects.filter(pk__in=list(inner_q)))

Alasdair

--
Alasdair Nicol
Developer, MEMSET

mail: alasd...@memset.com
 web: http://www.memset.com/

Memset Ltd., registration number 4504980. 25 Frederick Sanger Road, Guildford, 
Surrey, GU2 7YD, UK.

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



Re: change min_length in form __init__?

2012-01-13 Thread Alasdair Nicol

On 13/01/12 10:47, bruno desthuilliers wrote:

On Jan 11, 12:15 pm, galgal  wrote:

Is there any way, to change the field's *min_length* argument inside form
constructor? That doesn't work:

def __init__(self, *args, **kwargs):
 super(CreateTeamForm, self).__init__(*args, **kwargs)
 self.fields['primary_color'].min_length = 4

Assuming primary_color is a CharField, this should theoretically
JustWork AFAICT. What is the result ? ("doesn't work" is not really
descriptive...)


Hi Bruno,

I answered this question on Stack Overflow earlier this week [1].

When a field with min_length is initialised, a MinLengthValidator is 
added to the its validators. So if you set the min_length attribute 
after calling parent classes __init__ method, it is 'too late' for it to 
have any effect.


The solution is to change the field's validators in the __init__ method 
instead,


Cheers,
Alasdair

[1]: 
http://stackoverflow.com/questions/8818261/django-change-min-length-in-form-init/


--
Alasdair Nicol
Developer, MEMSET

mail: alasd...@memset.com
 web: http://www.memset.com/

Memset Ltd., registration number 4504980. 25 Frederick Sanger Road, Guildford, 
Surrey, GU2 7YD, UK.

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



Re: Class-Based Generic Views (CreateView) - field exclusions and defaults

2012-01-12 Thread Alasdair Nicol

On 11/01/12 20:54, Juergen Schackmann wrote:

if is use this code, as proposed by russ:
def form_valid(self, form):
self.object.user = ... (something meaningful.. e.g., 
self.request.user)

return super(CreateCampaignView, self).form_valid(form)

i get the error 'NoneType' object has no attribute 'user'. and 
actually, by looking at the source code, that is exactly what is 
supposed to happen in a create view: self.object is set to None, as 
you can see in BaseCreateView


def post(self, request, *args, **kwargs):
self.object = None
return super(BaseCreateView, self).post(request, *args, **kwargs)

am i the only one having this problem? any help is highly appreciated.
thanks
juergen
--
I agree that it looks like self.object is None, so you can't set 
self.object.user as Russ wrote.


How about the following:

def form_valid(self, form):
form.instance.user = request.user
return super(CreateCampaignView, self).form_valid(form)

I haven't had a chance to test the code. I hope that it works, or at 
least leads you in the right direction!


Regards,
Alasdair

--
Alasdair Nicol
Developer, MEMSET

mail: alasd...@memset.com
 web: http://www.memset.com/

Memset Ltd., registration number 4504980. 25 Frederick Sanger Road, Guildford, 
Surrey, GU2 7YD, UK.

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



Re: clean function for field that may be blank

2011-11-16 Thread Alasdair Nicol

On 16/11/11 14:32, Jaroslav Dobrek wrote:

Hello,

I have got a class Person:

class Person(models.Model):
 given_names = models.CharField(max_length=200)
 family_names = models.CharField(max_length=200)
 date_of_birth = models.DateField(blank=True)

and a class PersonForm:

class PersonForm(forms.ModelForm):

 def clean_date_of_birth(self):
 try:
 date_of_birth = self.cleaned_data['date_of_birth']
 if date_of_birth.year<  1890:
 raise forms.ValidationError(u"It is very improbable
for a person to be this old.")
 return date_of_birth
 except KeyError:
 pass

The code works as expected if I leave out "blank=True" in the field
date_of_birth of the class Person. But it doesn't work with
blank=True.

How does clean_date_of_birth have to look like, if date_of_birth is
optional?

Jaroslav



Hi Jaroslav,

When blank=True, you need to check that the user has entered a 
date_of_birth before you try to access its year.


def clean_date_of_birth(self):
date_of_birth = self.cleaned_data.get('date_of_birth')
if date_of_birth:
if date_of_birth.year < 1890:
raise forms.ValidationError(u"It is very improbable...")
    return date_of_birth

Regards,
Alasdair

--
Alasdair Nicol
Developer, MEMSET

mail: alasd...@memset.com
 web: http://www.memset.com/

Memset Ltd., registration number 4504980. 25 Frederick Sanger Road, Guildford, 
Surrey, GU2 7YD, UK.

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



Re: Strange traceback: DoesNotExist not callable

2011-10-20 Thread Alasdair Nicol

Hi João and Torsten,

On 20/10/11 18:53, João Pedro Francese wrote:

I've just stumbled upon the same problem in my code. I have no clue on
why it happened either. Did you ever get any progress on investigating
this issue?

Regards,
Joao

On Oct 7, 12:31 pm, Torsten Bronger
wrote:

Hall chen!

I examine a traceback that ends with

 ...

   File "/usr/lib/python2.6/dist-packages/django/db/models/query.py", line 
351,
 in get
 % (self.model._meta.object_name, num, kwargs))

 TypeError: 'DoesNotExist'objectisnotcallable

The error-triggering source code in query.py says

 def get(self, *args, **kwargs):
 """
 Performs the query and returns a singleobjectmatching the given
 keyword arguments.
 """
 clone = self.filter(*args, **kwargs)
 if self.query.can_filter():
 clone = clone.order_by()
 num = len(clone)
 if num == 1:
 return clone._result_cache[0]
 ifnotnum:
 raise self.model.DoesNotExist("%s matching query doesnotexist."
 % self.model._meta.object_name)
 raise self.model.MultipleObjectsReturned("get() returned more than one %s 
-- it returned %s! Lookup parameters were %s"
 % (self.model._meta.object_name, num, kwargs))

The last line triggers the error.  This is strange for two reasons:
First,DoesNotExistshould becallablefor all models.  And
secondly, there is noDoesNotExistin the last line but a
MultipleObjectsReturned.

My source code that is responsible for the error is:

 try:
 sample = self.samples.get()   # Here, the TypeError occurs
 except (Sample.DoesNotExist, Sample.MultipleObjectsReturned):
 pass
I've been caught out by this error before. In my case it was because I 
was not catching exceptions correctly *elsewhere* in my code. In another 
view, I had something like


try:
sample = self.samples.get()   # Here, the TypeError occurs
except Sample.DoesNotExist, Sample.MultipleObjectsReturned:
   pass

Without the parenthesis, it's equivalent to the following in Python 2.6+

except Sample.DoesNotExist as Sample.MultipleObjectsReturned:

The instance of the DoesNotExist exception overwrites 
Sample.MultipleObjectsReturned!


When the same process is handles a different request later on, you get 
the type error because your code is trying to call the DoesNotExist 
instance which has replaced Sample.MultipleObjectsReturned.


tschüss,

Alasdair

--
Alasdair Nicol
Developer, MEMSET

mail: alasd...@memset.com
 web: http://www.memset.com/

Memset Ltd., registration number 4504980. 25 Frederick Sanger Road, Guildford, 
Surrey, GU2 7YD, UK.

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



Re: Filtering html for django comments

2011-10-07 Thread Alasdair Nicol
To protect against injection, you *do* want to want to use the safe 
argument.


If you don't use the safe parameter, then the markdown filter will not 
escape any html in the input.


http://freewisdom.org/projects/python-markdown/Django

If you're not convinced, try including the following {{ text|markdown }} 
with and without the safe parameter!


text = """
alert(boo!);
**This is bold**
"""

Regards,

Alasdair


On 07/10/11 15:04, arkai...@gmail.com wrote:

Hi,
I am aware that Markdown is a formatting language like textile or any 
other.
It is just that i've seen other projects using {{var|markdown:"safe"}} 
to protect against injected html and I don't know if that is the same, 
better or worse that just {{var}} without disabling autoescape.


Thanks

--
Arkaitz


On Fri, Oct 7, 2011 at 2:50 PM, Tom Evans <mailto:tevans...@googlemail.com>> wrote:


On Fri, Oct 7, 2011 at 9:00 AM, arkai...@gmail.com
<mailto:arkai...@gmail.com> mailto:arkai...@gmail.com>> wrote:
> Hi all,
> I'm working on a comments addon for my app and I'm checking the
alternatives
> for urlizing and securing what users write in comments.
> I thought that just using Djangos default autoescape( not doing
anything)
> plus the |urlize filter like " {{comment|urlize}}" would be
enough, but I've
> seen examples in the web using "{{comment|markdown:'safe'}}" so
I was
> wondering if autoescape is not enough or people are using
"markdown:'safe'"
> for other reasons?
>
> Should I be concerned if I don't use markdown:"safe" ?
>
> Thanks

Markdown is a formatting language. People using that syntax enter
their comments in markdown, and use that to turn them into HTML.

Cheers

Tom

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


--
You received this message because you are subscribed to the Google 
Groups "Django users" group.

To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.



--
Alasdair Nicol
Developer, MEMSET

mail: alasd...@memset.com
 web: http://www.memset.com/

Memset Ltd., registration number 4504980. 25 Frederick Sanger Road, Guildford, 
Surrey, GU2 7YD, UK.

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



Re: ORM only/defer calls do not work on cross-table relations

2011-09-27 Thread Alasdair Nicol

Hi John,

Use select_related [1] to tell Django to 'follow' the foreign key. Try 
the following:


testmodels = 
models.ATestModel.objects.all().select_related('other').only('other__name')
print testmodels[0].other.name


Regards,
Alasdair

[1]: 
https://docs.djangoproject.com/en/dev/ref/models/querysets/#select-related


On 27/09/11 21:49, John wrote:

Hey,

I'm trying to improve the performance of a Django app, and noticed
that you can't seem to properly defer fields when making lookups with
joins.  To demonstrate, I set up a test project with the following
models:

class ATestModel(models.Model):
 other = models.ForeignKey('OtherModel')

class OtherModel(models.Model):
 name = models.CharField(max_length=32)

then, in the Django shell, I set up 10 'ATestModel's and two
'OtherModel's properly linked up, and ran the following:


from testmodule import models
testmodels = models.ATestModel.objects.all().only('other__name')
print testmodels[0].other.name

Test One

from django.db import connection
print '\n\n'.join([x['sql'] for x in connection.queries])

SELECT "testmodule_atestmodel"."id",
"testmodule_atestmodel"."other_id" FROM "testmodule_atestmodel" LIMIT
1

SELECT "testmodule_othermodel"."id", "testmodule_othermodel"."name"
FROM "testmodule_othermodel" WHERE "testmodule_othermodel"."id" = 1

I also re-ran that without the 'only' call:


testmodels = models.ATestModel.objects.all()
print testmodels[0].other.name

Test One

print '\n\n'.join([x['sql'] for x in connection.queries[2:]])

SELECT "testmodule_atestmodel"."id",
"testmodule_atestmodel"."other_id" FROM "testmodule_atestmodel" LIMIT
1

SELECT "testmodule_othermodel"."id", "testmodule_othermodel"."name"
FROM "testmodule_othermodel" WHERE "testmodule_othermodel"."id" = 1

The 'only' call does nothing, and two queries are made when one would
have sufficed (SELECT testmodule_othermodel.name FROM
testmodule_atestmodel LEFT JOIN testmodule_othermodel ON
testmodule_atestmodel.id = testmodule_othermodule.id).  This raises a
huge performance penalty for highly normalized schemas and I would
even go so far as to say it in fact makes it impossible to optimize
queries with a decently normalized schema.

My apologies if someone has brought this up before - I was unable to
see anything about it in the django tickets or mailing lists.




--
Alasdair Nicol
Developer, MEMSET

mail: alasd...@memset.com
 web: http://www.memset.com/

Memset Ltd., registration number 4504980. 25 Frederick Sanger Road, Guildford, 
Surrey, GU2 7YD, UK.

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



Re: AssertEquals __unicode__

2011-08-25 Thread Alasdair Nicol

On 25/08/11 11:34, Torsten wrote:

Hi

How do I do that right ?

I have a class like:

class Invoice
...
def __unicode__(self):
 return unicode(str(self.created_at.year)+'/'+str(self.id))

and an test here:


def test_invoice_number(self):
 invoice = Invoice.objects.create(created_at="2011-07-28",
customer_id=1, payable_at='2012-12-12')
 invoice.save()
 self.assertEqual("Invoice: 2011/1", invoice)


with the follwoing result:

File "/Users/torsten/PycharmProjects/invoiz/invoice/tests.py", line
22, in test_invoice_number
self.assertEqual("2011/1", invoice)
AssertionError: '2011/1' !=


Thanks for help

Torsten

You want to compare the unicode string for the object, so use the 
unicode function. The following should work:


self.assertEqual("Invoice: 2011/1", unicode(invoice))


Regards,
Alasdair

--
Alasdair Nicol
Developer, MEMSET

mail: alasd...@memset.com
 web: http://www.memset.com/

Memset Ltd., registration number 4504980. 25 Frederick Sanger Road, Guildford, 
Surrey, GU2 7YD, UK.

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



Re: [ANN]: FeinCMS v1.4.0.rc1

2011-08-08 Thread Alasdair Nicol

On 08/08/11 09:09, Matthias Kestenholz wrote:

Hello everyone

The first release candidate of FeinCMS v1.4 hit the streets yesterday
and is available at the usual places. Please note that the official
repository has been moved to the feincms organization on github and
does not live in my personal account anymore.

Great news Matthias! We're looking forward to using 1.4, especially the 
django-reversion support.


Regards,
Alasdair

--
Alasdair Nicol
Developer, MEMSET

mail: alasd...@memset.com
 web: http://www.memset.com/

Memset Ltd., registration number 4504980. 25 Frederick Sanger Road, Guildford, 
Surrey, GU2 7YD, UK.

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



Re: url names

2011-07-19 Thread Alasdair Nicol

On 19/07/11 11:08, NISA BALAKRISHNAN wrote:

how to add url names to the following entry in urls.py.

( r'^all/synchro/download/file/', "get_all_data_download" )


Use the url function [1]

url( r'^all/synchro/download/file/', "get_all_data_download", 
name="get_all_data_download" )


Alasdair

[1] https://docs.djangoproject.com/en/dev/topics/http/urls/#url

--
Alasdair Nicol
Developer, MEMSET

mail: alasd...@memset.com
 web: http://www.memset.com/

Memset Ltd., registration number 4504980. 25 Frederick Sanger Road, Guildford, 
Surrey, GU2 7YD, UK.

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



Re: Linking to Django Admin from 1.3

2011-07-14 Thread Alasdair Nicol

From the django docs on url namespaces [1]

Namespaced URLs are specified using the : operator. For example, the 
main index page of the admin application is referenced using 
admin:index. This indicates a namespace of admin, and a named URL of 
index.


So you link to the admin index in your template using:

{% url admin:index %}

For Django 1.3, the documented way [2] to include the admin site is:

*url(r'^admin/', include(admin.site.urls)),*


Regards,
Alasdair Nicol

[1] https://docs.djangoproject.com/en/dev/topics/http/urls/#url-namespaces
[2] https://docs.djangoproject.com/en/1.3/intro/tutorial02/


On 14/07/11 15:35, eric.frederich wrote:

Hello,

I am moving from 1.0.2 to 1.3 and am having problems linking to the
admin site from within a template.
I used to have this in my template...

 Django Admin

And I used to have this in my urls.py

 url(r'^admin/(.*)'  , admin.site.root, name='the-django-
admin'),

I'm sure this was hacky even back in 1.0.2
How should I link to the admin site's index from within a template?

I cannot hard code it to /admin because while this would work on
development, on production it needs to be /apps/admin
So I need to use the URL resoving mechanism so that the prefix gets
picked up based on which environment it is on.

So... simple question.  How do I link to the Django admin site from
within a template?

Thanks,
~Eric




--
Alasdair Nicol
Developer, MEMSET

mail: alasd...@memset.com
 web: http://www.memset.com/

Memset Ltd., registration number 4504980. 25 Frederick Sanger Road, Guildford, 
Surrey, GU2 7YD, UK.

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



Re: Multiple forms into one form/trouble accessing form fields

2011-06-15 Thread Alasdair Nicol

https://docs.djangoproject.com/en/dev/ref/forms/api/#prefixes-for-forms

Regards,
Alasdair

On 15/06/11 14:09, Thomas Weholt wrote:

I got several forms I need to display in one page and post to one
site. Actually, what I want to do is take all the fields from all the
forms and display them as one form and post all input to one view. To
avoid collision between the form fields I want to prefix the fields
somehow.

Say I got three forms:

class UserInputForm1(forms.Form):
 username = forms.CharField()
 password = forms.CharField()

class UserInputForm2(forms.Form):
 comment = forms.CharField()

class UserInputForm3(forms.Form):
 like = forms.BooleanField()

I want to put all fields, from all three forms, into one new form and
prefix each field so I know what form the field came from. How can I
do that? When I access the fields after creation it appears to be a
string.

An alternative to this is a FormWizard, but that makes the user click
thru a bunch of steps, which could be avoided if I could get all the
fields into one new form.




--
Alasdair Nicol
Developer, MEMSET

mail: alasd...@memset.com
 web: http://www.memset.com/

Memset Ltd., registration number 4504980. 25 Frederick Sanger Road, Guildford, 
Surrey, GU2 7YD, UK.

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



Re: VERY cheap django hosting?

2011-06-08 Thread Alasdair Nicol
I have used djangohosting.ch before and recommend them. As BR says it's 
very easy to deploy, and I thought their support was super.


Alasdair

On 08/06/11 22:13, Tiago Almeida wrote:

I use http://djangohosting.ch/ for a small company website and haven't
experienced any issues on the last 4 months.
It is a shared hosting account but the machine is quite beefy and
always idle :)
you pay 12€ every 3 months.
It is very easy to deploy django project there, unlike vps where you
have to configure everything.
BR,


On Jun 8, 7:30 am, raj  wrote:

Hey guys,
Just wondering if you could give me some hosts that are very cheap for
django hosting? Is hostgator any good? I really don't know what to
look for in a host. A lot of people are recommending web faction, but
its around $9 bucks a month. I was looking in the $5 bucks a month
range. Any ideas? Thank you.
-Raj



--
Alasdair Nicol
Developer, MEMSET Dedicated Hosting

mail: alasd...@memset.com
 web: http://www.memset.com/

Memset Ltd., registration number 4504980. 25 Frederick Sanger Road, Guildford, 
Surrey, GU2 7YD, UK.

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



Re: login -->then on success--> my custom page

2011-04-05 Thread Alasdair Nicol
If you only need to change the success url, then use the 
LOGIN_REDIRECT_URL setting [1]. You won't need to customise the login page.


Alasdair

[1] http://docs.djangoproject.com/en/dev/ref/settings/#login-redirect-url

On 05/04/11 10:14, GOUTAM KUMAR RANA wrote:
please help me to make or inherit a login page which on success goes 
to my custom page


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