--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/9897126d-b6ef-48f1-9f19-96ed98ce10e5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
I agree with Adam, we should never silently change submitted data at the model layer. My preference would be c), a form-level validation error that prevents saving.
Luke
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM1qVc3ovXb9PhzKY3jd__FURYX6Fy9r1WFrBpcpMy%2Bz%2BA%40mail.gmail.com.
Hi,
I would guess that one could use null byte to denote "empty
field" in Oracle for example. (I recall seeing such a convention
in one of our non-django apps). And that's to overcome limitation
that Oracle doesn't have real concept of empty string so we stored
single null byte to mark that.
--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/9897126d-b6ef-48f1-9f19-96ed98ce10e5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
-- Jani Tiainen
Is it even possible for null bytes to be copied into a text field and for them to be submitted? The original report uses Javascript to get them in there - https://code.djangoproject.com/ticket/28201
These pages suggests it is going to be really hard for users to be entering 0x00 accidentally:
- http://stackoverflow.com/questions/6961208/how-to-input-a-null-character-into-a-web-form
If we are talking about this kind of rare condition, I think a slightly obscure error message is fine. Defaulting to stripping any data would be a bad idea IMO, for the case where a backend is currently handling and storing 0x00 chars we should try hard not to break that.Franklin Schmidt wrote: > I agree that storing 0x00 in a UTF8 string is weird, but I am > converting a huge database to postgres, and in a huge database, weird > things happen. Using bytea for a text field just because one in a > million records has a 0x00 doesn't make sense to me. I did hack > around it in my conversion code to remove the 0x00 but I expect that > anyone else who tries converting a big database to postgres will also > confront this issue. That's the right solution. If you have 0x00 bytes in your text fields, you're much better off cleaning them away anyway, than trying to work around them.
-Heikki Linnakangas