Re: Charfield variable length

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+unsubscribe@googlegroups.com
> <mailto:django-users+unsubscribe@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+unsubscribe@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.