Upgrade failed - Table-Prefix not supportet?
Frank.dev - December 3, 2007 - 15:26
| Project: | Fullname field for CCK |
| Version: | 5.x-1.2 |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | rconstantine |
| Status: | closed |
Jump to:
Description
Hi,
im using Drupal-Installation (5.3) with DB-Table-Prefix ("abc_"). The upgrade of "Fullname-field" (5.x-1.1 => 5.x-1.2) failed (after run the update.php) with many (5) Errors. One of this:
Table 'datenbank.content_type_mitglied' doesn't exist query: ALTER TABLE content_type_mitglied ADD COLUMN field_name_suffix_preferred varchar(6) NOT NULL in /htdocs/drupal/includes/database.mysql.inc in Zeile 172.
The Fullname-Field-upgrade/Install-script search to table "content_type_mitglied" - "hopeless" without DBTable-prefix ("abc_")... The correctly name of this table "abc_content_type_mitglied".
Bad bad Error. ;-)
...an bad is my english, sorry.
#1
Strange. So far as I can tell, it should be working. The code that should be getting the table name (including the prefix) is:
$db_info = content_database_info($field);$table = $db_info['table'];
It looks to me that content_database_info may be to blame which is a function of the CCK module. Notice that it calls _content_tablename, which is supposed to figure out names for the tables. However, it looks like this code:
switch ("$version-$entity") {case '0-'. CONTENT_DB_STORAGE_PER_CONTENT_TYPE :
return "node_$name";
case '0-'. CONTENT_DB_STORAGE_PER_FIELD :
return "node_data_$name";
case '1003-'. CONTENT_DB_STORAGE_PER_CONTENT_TYPE :
return "content_type_$name";
case '1003-'. CONTENT_DB_STORAGE_PER_FIELD :
return "content_$name";
}
Seems the above code should get the database prefix and then return $prefix_content_type_$name.
So I would suggest that you open an issue at the CCK project and point them to this issue as a reference.
Meanwhile, you can change the code above by hand to read "abc_content_type_$name" and "abc_content_$name"; hardly ideal, but should work.
#2
Hi rconstantine,
thanks. :-)
I have post an new bugreport in the cck-projekt => http://drupal.org/node/197695
best regards
Serlo
#3
Okay. I'll close it for now, but if it turns out there is a problem with this module, please feel free to change the status back to 'active' and provide more info.
#4
CCK returns the non-prefixed tablename in those fields, by design. The problem here is actually in the install code. You have to change the following:
<?php
$ret[] = update_sql("ALTER TABLE {$table} ADD COLUMN ". $fieldname ."prefix varchar(6) NOT NULL");
?>
to the following, since otherwise the brackets get ignored and no prefixing is done.
<?php$ret[] = update_sql("ALTER TABLE {". $table ."} ADD COLUMN ". $fieldname ."prefix varchar(6) NOT NULL");
?>
We found that out the hard way when we tried doing the same thing in the CCK updates.
#5
Boy, is my face red. If that's not obvious, I don't know what is. Thanks KarenS.
Needless to say, until I make the change, just open up your install file and change any instances of {$table} to look like Karen's above.
Will upload a new version when I get a chance and will leave this open until I do.
#6
It's actually not all that obvious. We did it the same way you did originally, until the bug reports started coming in. :)
#7
Ok, i see, learning by doing. ;-)
But i have this questions:
I corrects the install code at the necessary places.
{$table}=>{". $table ."}. I replaced the old with the new module-files in directory - just like three days ago.Now, i see not the request to use the update.php. What now?
The old update of this module abborted -now it does not start any more... ;-)
#8
You can do two things. Either you can adjust your database's system table to reflect an older schema for this module (not recommended), or you can go to the module page, then click the update link, then expand the fieldset, then select the schema manually for this module and run the update again. You may get errors if any portion was previously successful, and you can safely ignore them. The idea is that between your first attempt and this one, you should get updated completely. If nothing was successful on your first attempt, then you should not get any errors this time.
Does that make sense?
#9
Thank you, the second option has finished successful the module-update.
Now you must correct only the file (cck_fullname.install) for download, for other users. ;-)
#10
OK. I'll roll out a new release this week.
#11
Great.
Wie in Germany says:
"Was Du heute kannst besorgen, das verschiebe nicht auf morgen!"
...since many many years. ;-)
#12
Automatically closed -- issue fixed for two weeks with no activity.