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 inappropriate for that type. I *could* probably change the model type to CharField and override the ModelForm widget as IPAddressField to get form-level validation, and so the DB syntax error goes away, but isn't that a bug? -- 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 group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
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 get it right? Come on, this one can't be that harder than implementing multi-key PKs? :) -- 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 group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
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 group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
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 the scenes. -- 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 group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
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 Postgres' inet type. I believe Django shouldn't be disregarding null=true for an IPAddressField when dealing with Postgres. -- 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-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
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-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
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 number of trailing slashes are completely optional? The APPEND_SLASH setting would then be important in very specific cases only. --~--~-~--~~~---~--~~ 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 group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
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 only match a single > trailing slash. > I was just special-casing the backslash, which is special anyway, otherwise APPEND_SLASH wouldn't exist. Moreover, hello and hello/ (and hello/) _are_ the same URL to Django, otherwise it wouldn't redirect to the url with the slash appended. APPEND_SLASH looks more like a hack, so why not treat the URLs the same from the beginning? This is all I was proposing. > However, it still wouldn't be a good idea to deploy this pattern. Some > search engines (Google being a notable and prominent example) penalize > websites that post identical content on multiple different URLs, as > this is a common marker of SEO spam. Deploying hello/*? or hello/?$ > means that multiple URLs will serve the same content. Problems with > trailing slashes notwithstanding, the APPEND_SLASH approach uses a > redirect, which doesn't attract the same 'Google penalty'. > Don't Google folks special-case the trailing slash and assume that URLs that only differ in the amount of trailing slashes (0 or more) are the same? Too bad then. --~--~-~--~~~---~--~~ 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 group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
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 to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
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
treated like a normal char in this regard, i.e. the difference between
r'hello' and r'hello/' isn't the same as the difference between
r'hello1' and r'hello2', at least I think so, and Django thinks so by
redirecting url to url/ when the former isn't found (subject to
APPEND_SLASH), but your opinion may be different.
> I am a strong -1 to your ideas about not making slash
> default, or that anything here is a /
I'm not sure I understand you, but all I proposed was r'^foo/*$'
instead of r'^foo/$', i.e. making trailing slashes optional (unless
Google robots penalize for that).
> Those are most definitely the same, and this is by choice and by user
> convention. I am a strong -1 to your ideas about not making slash
> default, or that anything here is a /. If APPEND_SLASH was a hack,
> then why does every webserver have equivalent functionality to emulate
> the add a trailing / behavior?
>
FWIW Apache does the redirect when it comes across a FS directory as
the last part of the path, but does Django care about FS with its
Smart URLs?
Or would one prefer opening http://example.com/user/21 and being
redirected to http://example.com/user/21/ as per default settings? At
least Chapter 3 of the online djangobook 2.0 puts / at the end of
almost all URLs, so the redirect is unavoidable.
Unless someone kindly proves me wrong, I really do think trailing
slashes in the URL should be optional, but this probably wouldn't
happen until Django 3.x
--~--~-~--~~~---~--~~
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 group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
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 already *up > to you*. If you want trailing slashes to be optional: > > 1. Set APPEND_SLASH to False. > 2. Write your urlconfs with optional slashes. > 3. There is no step three. > > Django itself makes no assumptions about how you'd like to design your > URLs. Behavior like APPEND_SLASH and PREPEND_WWW are shortcuts for > common desires, but both are incredibly easy to disable. > Yup, they can be any value, APPEND_SLASH wasn't the main point. At least djangobook teaches us to end all complete URLs in a slash, which IMHO should really be optional, so that the regex matches with or without the trailing slash(es) in the actual URL, _and_ without incurring the HTTP round-trip through redirection. Just a suggestion, please don't take it too harshly ;) > Why don't you back up a step: What are you trying to do that isn't working? Nothing, really, It was just a design suggestion. --~--~-~--~~~---~--~~ 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 group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
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-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
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 "/", which Django's web- server logs on the console: [08/Mar/2009 14:26:07] "GET /search HTTP/1.1" 200 205 [08/Mar/2009 14:26:10] "GET /?q= HTTP/1.1" 200 17 i.e. the first line shows me opening the form, and the next one logs form submission, i.e. no HTTP-level redirects are ever done. my urlpatterns looks like this: ... (r'^search/*$', search), ... that is, the trailing slash is optional. Very interestingly, the "." action submits correctly to itself only if I open the form as "http:// example.com/search/", not as "http://example.com/search"; in the first place, as the Django Book recommends. So it would be more correct to say that "action="." submits the form to the same URL up to and including the trailing slash, ignoring everything after it". --~--~-~--~~~---~--~~ 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 group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
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 the book is written by two of the primary > authors of Django and being updated by one of them (Adrian), this list > isn't the place to report bugs, since we have nothing to do with the > content of that book. Good idea, thanks. I can't use the comment system, though: nothing happens according to the docs at http://www.djangobook.com/about/comments/ --~--~-~--~~~---~--~~ 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 group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
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-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
