On 24/01/2019 9:14 am, 'Odile Lambert' via Django users wrote:
Hello
I have problems with the Charfield max_length. In the source code, the
possibility exists to have max_length = None but it does not pass
Django check when models.py. contains a charfield = None
I can understand that there is a need for such a max_length form the
database point of view .
When you run migrate it establishes the size of the Char field *in the
database*. Therefore it can only be set once per migration.
My need is the following:
I have a set of fields whose content in the database is a binary code
of maximum 180 bits. Most of the time it will be much shorter and
there is in the form a field (max size) giving this maximum size.
The user needs to input this field in the database as a Character
string of 0 and 1. using hexadecimal fields would be very unpractical.
Last but not least, I am using the admin to enter these data in the
database.
In a first shot, I used a Charfield and*I overwrote the field in the
init to set the maximum length to the value chosen by the user. I also
modifed the attributes of the widget. But at the end the HTML contains
a texinput with the max length set in the model.
*
Is this an admin feature or did I miss something?
A TextField is a varying length character field. Might be of interest.
A binary field requires bytes not text. I think if I needed binary data
entered by a user I would use a CharField with a reasonable max_length
and in the model.save() method I would convert/interpret the data
entered into precisely the binary format I needed and then
programmatically store it into a "parallel" binary field. I would
probably make it readonly in the Admin or just not display it.
I'm not sure about using binary fields with a choice attribute but that
might be another thing to research.
You can certainly use choices in a CharField to totally restrict the
data entered.
. Any other suggestion on how to handle these fields would be welcomed.
It might be easier to offer advice if your use-case was more clear.
--
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/23ff10f1-41d5-8da1-18a4-07d457be8756%40laposte.net
<https://groups.google.com/d/msgid/django-users/23ff10f1-41d5-8da1-18a4-07d457be8756%40laposte.net?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
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/e55ea10b-7fc6-efd9-ec87-02b5b75368f2%40dewhirst.com.au.
For more options, visit https://groups.google.com/d/optout.
