Primary keys are declared NULL
bastos - March 8, 2008 - 19:19
| Project: | Integrated Metatags |
| Version: | 6.x-1.0-beta |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Jump to:
Description
Hi,
I'm using Schema module on my Drupal6 site. and it shows tables for which the schema and database are different.
int_meta_fields.type is part of the primary key but is not specified to be 'not null'.
- int_meta_fields
- column type:
declared: array('type' => 'varchar', 'length' => 32, 'not null' => FALSE)
actual: array('type' => 'varchar', 'length' => '32', 'not null' => TRUE, 'default' => '') - column type:
declared: array('type' => 'varchar', 'length' => 32, 'not null' => FALSE)
actual: array('type' => 'varchar', 'length' => '32', 'not null' => TRUE, 'default' => '')
Thank you for your work.
#1
Interesting. I actually did that on purpose, with a default being set. As implemented today, the "default" configuration is an empty string as opposed to a NULL value in that table. NULL would thus not make any sense since it would be meaningless to the code.
Do you have any links on best practices for something like this? I'm willing to re-evaluate how the schema is setup if I can understand why one way is better than the other.
#2
It is always suggested that primary keys are set to be
NOT NULL.If the code doesn't assign
NULLvalues to the primary keys, that is a reason more to set the primary keys toNOT NULL; if the code would assing aNULLvalue to the primary keys, then the code should be changed.#3
#4
I've fixed this internally in D6, but still need to port it to the D5 branch.
#5
#6
The Schema module no longer shows the schema from this module as mismatched anymore in the BETA6 release.
#7
Automatically closed -- issue fixed for two weeks with no activity.