Re: django.contrib.admin and null=True

On Tue, Dec 7, 2010 at 4:26 PM, schinckel wrote: > I think this is broken behaviour: NULL values are semantically > different to empty strings, and in certain cases (I think it was > IPAddressField, but I will have another look later), it would fail to > write to the database. > > Is there a reaso

Re: django.contrib.admin and null=True

You might consider reading http://docs.djangoproject.com/en/dev/ref/models/fields/#null. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group

Re: Is their much benefit In using a second hidden salt

I see, I really had not give much though to the points that you make. I guess the secret salt really does create some possible inconvenience and should be feature left up to developers to implement as you say. Thanks for the input. On Dec 7, 6:37 pm, Ian Kelly wrote: > On Tue, Dec 7, 2010 at 2:27

Re: Is their much benefit In using a second hidden salt

On Tue, Dec 7, 2010 at 2:27 PM, andy wrote: > However I'm a bit curious about the significance of adding a second > salt to the password before it is hashed and then using the regular > per-user salt. Currently my opinion is that their is added benefit > since it make dictionary attacks more chall

django.contrib.admin and null=True

I haven't been able to find any documentation about this, but would be happy to be pointed in the right direction. When you use null=True in a field, and then use that model in the admin, it will not save NULL to the database, but will instead save an empty string (or attempt to). I think this is

Is their much benefit In using a second hidden salt

So I was having a bit of confusion over the method that django uses to protect passwords. The issues I had was that It seen unsecured to have the salt publicly available in the database since anyone who gets hold of the database would know the salt. After rereading the django book and doing some ad

Re: Migrating to class-based views and django.core.urlresolvers.reverse

Again this topic is now in django-user land. I do this in views.py if want the decorator on all methods (get|post). myview = login_required(MyView.as_view()) On Dec 7, 2010, at 1:10 PM, Daniel Swarbrick wrote: > That is indeed in the docs, and I have seen that. What eludes me is > how to us

Re: Migrating to class-based views and django.core.urlresolvers.reverse

That is indeed in the docs, and I have seen that. What eludes me is how to use decorators more complex than login_required() from within urls.py. For example, this works fine: from django.contrib.auth.decorators import user_passes_test from django.utils.decorators import method_decorator from dja

Re: Migrating to class-based views and django.core.urlresolvers.reverse

On 7 December 2010 18:08, Daniel Swarbrick wrote: > Forgetting namespaces or existing named URL patterns for a moment, the > major difference is that with function-based views, we were giving a > qualified "module.function" parameter to reverse() or {% url %}. > > How can we do that with class-bas

Re: Migrating to class-based views and django.core.urlresolvers.reverse

Hi Daniel On Tue, Dec 7, 2010 at 6:08 PM, Daniel Swarbrick wrote: > Forgetting namespaces or existing named URL patterns for a moment, the > major difference is that with function-based views, we were giving a > qualified "module.function" parameter to reverse() or {% url %}. > > How can we do th

Re: Migrating to class-based views and django.core.urlresolvers.reverse

Forgetting namespaces or existing named URL patterns for a moment, the major difference is that with function-based views, we were giving a qualified "module.function" parameter to reverse() or {% url %}. How can we do that with class-based views, without naming every URL pattern? Or is it not pos

Re: Feedback required: #14799 -- Problem with setting up test databases

Russell Keith-Magee ha scritto: On Tue, Dec 7, 2010 at 11:21 PM, mpaolini wrote: Maybe unrelated... have you had a look at #14662? It's related, but in the sense that it's the manual manifestation of what #14799 needed to correct. The contenttype and auth post_syncdb handlers ignore

Re: Feedback required: #14799 -- Problem with setting up test databases

On Tue, Dec 7, 2010 at 11:21 PM, mpaolini wrote: > Maybe unrelated... > > have you had a look at #14662? It's related, but in the sense that it's the manual manifestation of what #14799 needed to correct. The contenttype and auth post_syncdb handlers ignore --db by design -- they should be (and

Re: Feedback required: #14799 -- Problem with setting up test databases

Maybe unrelated... have you had a look at #14662? Marco -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-develop

call_command retval

I think call_command should return something significant to let the caller know if the command was successful or not. Another issue ralated to this is: having an error retcode when calling management commands from commandline The problem now is that for instance loaddata swallows all exception

Re: Migrating to class-based views and django.core.urlresolvers.reverse

Hi Daniel, I'm not core developer, but I think http://docs.djangoproject.com/en/dev/topics/http/urls/#defining-url-namespaces should be used. you can use reverse("yournamespace:someview"), and it's also cool to do things like this in settings.py: reverse_lazy = lazy(reverse, str) LOGIN_REDIRECT_

Migrating to class-based views and django.core.urlresolvers.reverse

I have been tracking the development of class-based views for a few weeks now, and am just starting to adapt some of my work-in-progress sites. This post is in a bit of a grey area between django-users and django-developers, but I'm curious what is suggested for sites that make heavy use of django.