On 2/20/06, hugo <[EMAIL PROTECTED]> wrote:
>
> blank=True with implicit null=True isn't probably what users would
> expect when applying it to charfields. And having a rule where
> charfields have null=False in combination with blank=True and
> non-charfields have null=True with blank=True is rath
On Sunday 19 February 2006 00:21, Tom Tobin wrote:
> Hmm; while it would be good to support edge cases like that, I think
> the default should make general-use cases easier. Maybe null=True
> should automatically set blank=True for non-string fields, but still
> allow one to then explicitly set
>What are your thoughts on the modified proposal stated in my reply to
>Luke (i.e., keep both, but have blank automatically set to True when
>null=True and then allow the explicit setting of blank=False)?
blank=True with implicit null=True isn't probably what users would
expect when applying it t
On 2/20/06, hugo <[EMAIL PROTECTED]> wrote:
>
> >There currently seems to be a bit of redundancy with regards to the
> >"blank" and "null" field options
>
> So I am -1 on the proposal to get rid of one of those two. Every
> combination (even null=True and blank=False - think about legacy data)
> ma
>There currently seems to be a bit of redundancy with regards to the
>"blank" and "null" field options; tickets #1043 and #1353 seem to be
>the inverse of one another, each addressing that one must specify both
>blank=True and null=True to get the expected behavior (i.e., being
>able to specify an
On 2/18/06, Luke Plant <[EMAIL PROTECTED]> wrote:
>
> On Saturday 18 February 2006 23:27, Tom Tobin wrote:
> > Is there a scenario in which it would be
> > useful to only specify one of these options, and not the other, for
> > non-string fields?
>
> I have legacy data which requires allowing nulls
On Saturday 18 February 2006 23:27, Tom Tobin wrote:
> Is there a scenario in which it would be
> useful to only specify one of these options, and not the other, for
> non-string fields? I can't imagine one offhand; one would either be
> able to save null values but be unable to enter them in the
There currently seems to be a bit of redundancy with regards to the
"blank" and "null" field options; tickets #1043 and #1353 seem to be
the inverse of one another, each addressing that one must specify both
blank=True and null=True to get the expected behavior (i.e., being
able to specify and save
