Re: models.IPAddressField not saved as NULL

On Nov 17, 7:16 pm, rihad wrote: > So is there any suggested workaround if one wishes to keep type inet > at the PostgreSQL level? BTW: changing the field type to GenericIPAddress worked flawlessly. Wow. "manage.py sqlall" revealed that it's still Postgres inet type behind

Re: models.IPAddressField not saved as NULL

So is there any suggested workaround if one wishes to keep type inet at the PostgreSQL level? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this

Re: models.IPAddressField not saved as NULL

On Nov 17, 5:14 pm, Karen Tracey wrote: > > Yes, an old bug:https://code.djangoproject.com/ticket/5622 https://code.djangoproject.com/attachment/ticket/5622/empty-ip-2.diff Probably this simple fix breaks some core design principle badly, and that's why 17 months haven't been enough time to ge

models.IPAddressField not saved as NULL

I have a model field: models.IPAddressField(verbose_name="access IP address", blank=True, null=True) that I attempt to save through a ModelForm. Despite the settings above, instead of NULL, Django tries to save the empty field (mapped to Postgres' inet type) as an empty string E'' , which is inap

Re: IPAddressField inserted as empty string although null=True

Yes, that was me && me, thank you :) Going on to learn Django... -- 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-

IPAddressField inserted as empty string although null=True

I have these fields in a model: ipaddr1 = models.IPAddressField() ipaddr2 = models.IPAddressField(blank=True, null=True) When I "wrap" this model in a ModelForm, fill the form, and call form.save(), empty ipaddr2 gets inserted as an empty string, causing database errors for Postgr

Re: form action="."

> When the updated version of Chapter 7 of the django boook is released > online, if the same description persists, it would be worth making a > comment over there. Well, I'd hate sounding mean, but the wording was already taken from v2.0: http://www.djangobook.com/en/2.0/chapter07/ > Although th

form action="."

Chapter 7 of The Django Book says this: The action="." means “Submit the form to the same URL as the current page.” I'm not sure this is standard or not, but it doesn't do what's expected at least on Firefox 3.0.6 (Iceweasel of Debian 5.0 stable): the form is simply submitted to an emtpy URL "

Re: Small URLconf suggestion

OK, I see, thanks. It was just my point view that you devs might consider for the future. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develope

Re: Small URLconf suggestion

On Feb 22, 7:47 pm, Jacob Kaplan-Moss wrote: > On Sun, Feb 22, 2009 at 9:37 AM, rihad wrote: > > Unless someone kindly proves me wrong, I really do think trailing > > slashes in the URL should be optional, > > As Russ already said -- did you read his post? -- this is alre

Re: Small URLconf suggestion

On Feb 22, 5:29 pm, George Vilches wrote: > Take this example: > > urlpatterns = patterns('', >      (r'hello', 'view1'), >      (r'hello/', 'view2'), > ) > (I assume both ^ and $ are in their place) Relying on the difference in only the trailing slashes is, ugh, awkward. Slash shouldn't be trea

Re: Small URLconf suggestion

On Feb 22, 4:44 pm, rihad wrote: > amount of trailing slashes number of trailing slashes. Sorry for my English. ;-/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post

Re: Small URLconf suggestion

On Feb 22, 3:55 pm, Russell Keith-Magee wrote: > So - what exactly are you proposing that we change in Django? > > Looking at your proposal as a purely end-user suggestion: using > 'hello/*$' means that hello// will match your URL pattern. > 'hello/?$' would be a safer match, as it would on

Small URLconf suggestion

Hi, devs, I'm sure I'm not the only user who doesn't like the look of trailing slashes in URLs, or more precisely, the difference in behavior that they imply for Django users. How about simply changing this: (r'^hello/$', hello), to this (r'^hello/*$', hello), so that any numbe

Is newforms-admin there yet?

Hi devs, I'd like to know whether the "newforms-admin" branch has already been integrated? Thanks. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django