Thanks for feedback. Created ticket for the deprecation:
https://code.djangoproject.com/ticket/26154
On Thursday, January 21, 2016 at 3:06:39 AM UTC-5, Shai Berger wrote:
>
> On Thursday 21 January 2016 09:59:49 Aymeric Augustin wrote:
> > > On 21 janv. 2016, at 07:24, Josh Smeaton
On Thursday 21 January 2016 09:59:49 Aymeric Augustin wrote:
> > On 21 janv. 2016, at 07:24, Josh Smeaton 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
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.
On Thu, 21 Jan 2016 at 19:00, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> > On 21 janv. 2016,
> On 21 janv. 2016, at 07:24, Josh Smeaton 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
>> 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
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,
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