Posted by mikegoodwin on March 9, 2007 at 1:11pm
9 followers
| Project: | Drupal core |
| Version: | 6.x-dev |
| Component: | node system |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
I am trying to develop a Drupal site for my research group. I have made a content type 'publication' that is user for all of our journal articles. I have made custom fields and everything is working well, except that I would like the title field to have a longer maximum length. Some of our publications have very long titles which aren't fitting in the standard Title field. I would think that this would involve a minor change in the MySQL tables, but I'm not completely sure. Can someone let me know how to fix this? I would prefer a permanent solution and not something that would need to be re-done every time Drupal is updated, modified, etc. Thanks.
Comments
#1
Here's a quick patch to increase it from 128 to 255. I haven't had time to test it unfortunately.
#2
Assigning.
#3
Synced and tested to work fine on MySQL at least.
#4
Synced.
#5
:( patch no longer applies cleanly
# patch -p0 < node_title_255_1.patch
patching file modules/node/node.module
Hunk #1 succeeded at 3148 (offset 98 lines).
patching file modules/system/system.install
Hunk #1 FAILED at 380.
Hunk #2 FAILED at 417.
Hunk #3 FAILED at 866.
Hunk #4 FAILED at 903.
Hunk #5 succeeded at 3362 (offset -503 lines).
4 out of 5 hunks FAILED -- saving rejects to file modules/system/system.install.rej
#6
Updated patch to HEAD and schema API
#7
Tested (including upgrade path) and works. RTBC.
#8
Please make the title field TEXT rather than just imposing another arbitrary limit (which still isn't long enough). Patch here: http://drupal.org/node/103083
#9
This is still a patch, and still RTBC. Whether we should keep it as varchar or migrate to text would be up to the core committers, however I have the sneaking suspicion that a text field might have performance implications...
#10
Committed to CVS HEAD. Thanks.
#11
I don't think the upgrade path is reliable. You can't rely on the 'current' state of a schema in an upgrade function, because you can't predict what the schema will be by the time the update is executed (I should _really_ bookmark this link where Barry explains that much better than I do). Probably not that serious in this particular case, but it sets bad example anyway.
Attached patch corrects the upgrade path to what I understand to be the right way.
Side note : that's an easy mistake to make, and db_update_field function sure is tempting - should we really leave it as an API function or prefix it with '_' ?
#12
Yeah it is a little confusing. I think it should just be pointed out in the documentation for db_update_field.
In any case, the patch looks good and works fine.
#13
Sorry, that was my mistake. I had looked at system_update_6019() as a reference but probably should have done a bit more research on schema updates.
#14
true, system_update_6019 looks funny. Then again, I think it's precisely one of the schema patch updates (probably written by barry ?) so I'm not sure what to think about those. A word of comment could probably be used here ?
#15
yched is right. db_update_field() is not safe for hook_update_n() functions, system_update_6019() is broken, and his patch in #11 is the correct solution.
This situation is not only about the node title field so I created a new issue for it: http://drupal.org/node/156741. I think this issue should be changed back to 'fixed' as node titles can now be 255 chars as requested.
#16
Thanks for chiming in bjaspan. Committed.
#17
Barry, in http://drupal.org/node/156741 you write :
db_change_field() does not automatically re-create any keys or indexes in which changed column is involved, so if the column is involved in a key or index it must be explicitly dropped and re-created.
node.title is used in the following index (node.schema) :
'node_title_type' => array('title', array('type', 4))
So i guess this means we are missing the index too here ?
#18
Huh. Yes. The funny thing is I specifically checked for that before saying this should be marked fixed, but somehow I missed it.
So, I'm sorry for saying the patch was correct. It needs a db_drop_index() and db_add_index() wrapped around the call to db_change_field() for node.title. I am pretty confident that after making this update on pgsql, schema.module will report that the node table is missing an index. This doesn't happen on mysql due to the different way column changes are handled. I am unable to test this at the moment because head update is too broken (in part because of http://drupal.org/node/152383 killing INSERT INTO {batch}).
I am currently immersed in trying to get update.php working on pgsql well enough to test http://drupal.org/node/156741. When I'm done, I'll include this fix in that patch since it is basically for the same problem (there will be several required index drop/adds for that patch, too).
#19
I have verified that, on pgsql, running system_update_6025 causes schema.module to report: "node: indexes node_title_type: missing in database".
#20