| Project: | Ubercart |
| Version: | 6.x-2.0-rc7 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
uc_store_schema contains the following declaration:
<?php
$schema['uc_countries'] = array(
'fields' => array(
'country_id' => array(
'type' => 'serial',
'unsigned' => TRUE,
'not null' => TRUE,
),
...
);
?>The 'serial' type specifically refers to auto_increment fields. I guess that at some point in the past this was an arbitrary ID, but since then it has been repurposed to reference ISO-3166 numeric IDs.
This distinction doesn't make much difference at the moment, since the official Ubercart policy on country def files is still to INSERT the data directly using a db_query() call, but if the country system is ever to be updated to use the drupal_write_record() function it's a change that will have to be made.
TBH the whole country system should be updated so it's less of a manual insert process and more of a "declare values to be imported" thing - not unlike a hook_schema implementation - but that's a matter for another time.
Comments
#1
For "it's a change that will have to be made" read "this should be changed to an 'int' type field". I could have sworn I'd actually mentioned that earlier in the issue. Memory's the first thing to go, evidently.
(With a 'serial' field, any call to drupal_write_record() actively ignores any value in the field in favour of the internal auto_incremented sequence. I learned this to my cost when I was trying to manually add some arbitrary countries...)
#2
Yeah, this should be fixed before the 2.0 release.
#3
I hate having to switch on $GLOBALS['db_type'] anymore, but there's not much I can do about it in this case. I really hope they've made this task easier in Drupal 7.
#4
Update patch worked fine for me. Committing.
#5
Automatically closed -- issue fixed for 2 weeks with no activity.