deprecate CommaSeparatedIntegerField?

[Tim Graham]

A proposal has been raised to change the validation for CommaSeparatedIntegerField to allow negative numbers [1]. This is obviously backwards-incompatible, so I don't think it'll fly without some option to control the behavior, however, I wanted to ask if there's any reason not to deprecate the field at this point. From a quick glance, I believe it could be replaced with CharField(validators=[validate_comma_separated_integer_list]). The only database storage difference is on Oracle:

        'CharField': 'NVARCHAR2(%(max_length)s)',
        'CommaSeparatedIntegerField': 'VARCHAR2(%(max_length)s)',

Is this difference meaningful? Are there any third-party database backends that provide a special storage type for comma-separated integers such that it deserves a separate field?

[1] https://code.djangoproject.com/ticket/26107#ticket

[Shai Berger]

On Wednesday 20 January 2016 23:48:59 Tim Graham wrote:
> A proposal has been raised to change the validation for
> CommaSeparatedIntegerField to allow negative numbers [1]. This is obviously
> backwards-incompatible, so I don't think it'll fly without some option to
> control the behavior, however, I wanted to ask if there's any reason not to
> deprecate the field at this point. From a quick glance, I believe it could
> be replaced with
> CharField(validators=[validate_comma_separated_integer_list]). The only
> database storage difference is on Oracle:
>
> 'CharField': 'NVARCHAR2(%(max_length)s)',
> 'CommaSeparatedIntegerField': 'VARCHAR2(%(max_length)s)',
>
> Is this difference meaningful?

<guess from="memory"> The two field types use different encodings, and on oracle
the maximum field length for character columns is in bytes rather than
characters; so, in many settimgs, I think you'll be able to store twice as
many numbers in a CommaSeparatedIntegerField as in the equivalent CharField.
</guess>

It's an edge case, either way (who puts hundreds of numbers in such a field?)

Shai.

[Josh Smeaton]

>> It's an edge case, either way (who puts hundreds of numbers in such a field?) 

I'm not saying it's good or right, but I can easily see how people would store hundreds of comma separated values as a poor version of a m2m table. I'm not sure that the difference between NVARCHAR2 and VARCHAR2 would be meaningful to that use case, but it's something to consider.

I'm in favour of making the change, just call it out as a backwards compatibility.

[Aymeric Augustin]

> On 21 janv. 2016, at 07:24, Josh Smeaton <josh.s...@gmail.com> wrote:
>
> I'm in favour of making the change, just call it out as a backwards compatibility.

If I understand correctly, Oracle users encountering this issue would just have to adjust the field length?

That sounds acceptable.

--
Aymeric.

[Josh Smeaton]

No they couldn't just change the field length as its already max for that type. They would somehow have to change the type of the field but I don't think that's something we expose.

--
You received this message because you are subscribed to a topic in the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/wfp9qNpNpaQ/unsubscribe.
To unsubscribe from this group and all its topics, 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/A7B62982-445F-4D56-9966-2E2FBA197888%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

[Shai Berger]

On Thursday 21 January 2016 09:59:49 Aymeric Augustin wrote:
> > On 21 janv. 2016, at 07:24, Josh Smeaton <josh.s...@gmail.com> wrote:
> >
> > I'm in favour of making the change, just call it out as a backwards
> > compatibility.
>
> If I understand correctly, Oracle users encountering this issue would just
> have to adjust the field length?
>

If their field is short enough to begin with. There's a hard limit of 4000
bytes; if they need more, they'll need to change from a charfield with Tim's
validator to a TextField, and that, in turn, will also force them to change
queries with grouping in non-trivial ways.

Shai.

[Tim Graham]

Thanks for feedback. Created ticket for the deprecation: https://code.djangoproject.com/ticket/26154