| Package home | Report new bug | New search | Development Roadmap | Status: Open | Feedback | All | Closed Since Version 0.8.6 |
| Bug #15276 | Upgrading setting NOT NULL column default value to NULL | ||
|---|---|---|---|
| Submitted: | 2008-12-09 14:58 UTC | ||
| From: | yunosh | Assigned: | |
| Status: | Open | Package: | MDB2_Schema (version CVS) |
| PHP Version: | Irrelevant | OS: | |
| Roadmaps: | (Not assigned) | ||
[2008-12-09 14:58 UTC] yunosh
(Jan Schneider)
Description:
------------
If during a field update the default value is no longer set, the default value is set to NULL. When this happens, a check is missing whether this is allowed at all. The attached patch fixes this.
Alternatively this check might happen where the actual update query is build.
Comments
[2009-02-22 19:41 UTC] ifeghali
(Igor Feghali)
-Status: Open
+Status: Feedback
Hello Jan,
If there is no "default" in the new field definition, shouldn't we assume the field isn't "notnull" also ?
Say Field A is NOT NULL DEFAULT "FOO". It would make no sense to remove the <default> tag from the new XML schema but leave <notnull> = 1.
What do you think ? [2009-02-24 19:56 UTC] yunosh
(Jan Schneider)
I don't think we should assume too much. I'd prefer to get an error instead if I try to unset the default value on a NOT NULL column. This way the schema author can resolve that conflict manually to exactly do what he wants. That's better than guessing, I think.
[2009-06-30 22:37 UTC] hschletz
(Holger Schletz)
The current behavior is exactly what I'd expect: when no default is specified it is implicitly set to NULL. This is perfectly valid even for NOT NULL columns: In that case you will have to explicitly specify a non-null value upon inserting/updating. I can see absolutely no reason to treat this as an error or even messing with pseudo-null-values (like empty strings, which can cause problems, see #14209 and #14650)
Set constraints and defaults wisely. Should the current behavior ever be changed, please make it optional as this would break many existing schemas for no good reason.
[2009-07-01 00:24 UTC] hschletz
(Holger Schletz)
My last comment is not 100% correct: Setting the default to NULL is only appropriate with force_defaults set to false. The initial report does not mention the state of this setting.
With force_defaults set to true, the default value should be set to the appropriate NULL-surrogate (0, empty string...). This does not happen, and this is to be considered a bug. However, the supplied patch addresses the issue in a wrong way since it incorrectly assumes the combination "NOT NULL" + "DEFAULT NULL" to be invalid.
I strongly suggest to set force_defaults to false and manually set non-null defaults where they are really needed. Beside the mentioned issues with empty strings, things get really, really ugly with date and timestamp columns (1970-01-01, anyone?).