#26154 closed Cleanup/optimization (fixed)
Deprecate CommaSeparatedIntegerField
Reported by: | Tim Graham | Owned by: | Tobin Brown |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | yes |
Easy pickings: | no | UI/UX: | no |
Description
As proposed on django-developers, CommaSeparatedIntegerField
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)',
There are some upgrade considerations described on the mailing list that'll need to be mentioned for Oracle users.
See the migration topic guide for an explanation of how to deprecate the field, as well as the deprecating a feature guide.
Change History (11)
comment:1 by , 9 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:2 by , 9 years ago
comment:3 by , 9 years ago
I'd choose W901
to follow fields.W900: IPAddressField has been deprecated.
(reference).
comment:4 by , 9 years ago
Great! Thanks for the quick response. One more question. In test cases that use CommaSeparatedIntegerField
in the model definition (example) would it be better to add the ignore_warnings
decorator or change the field to use CharField(validators=[csi_validator])
comment:5 by , 9 years ago
It should use ignore_warnings
-- you might use 33457cd3b0da69320d3f66bb6d5a673950c5032f as a rough template to see what changes were made last time we did this (of course that's at the end of the deprecation period).
comment:6 by , 9 years ago
Do I use RemovedInDjango20Warning
? I thought the next version was going to be 1.10
comment:9 by , 9 years ago
Has patch: | set |
---|---|
Patch needs improvement: | set |
Left comments for improvement on the PR.
In the docs for deprecating the field it asks me to pick a unique id for the field.
'id': 'fields.W900', # pick a unique ID for your field.
Is there a convention I should follow, or do I just pick a number that doesn't already exist with another field?