Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
There is bug in system.install in system.module. Column fid in table {files} should have been serial type for PostgreSQL database (line).
Comment | File | Size | Author |
---|---|---|---|
#13 | system.install_20061130_1640_patch.txt | 770 bytes | sammys |
#12 | system.install_9.patch | 2.85 KB | havran |
#9 | system.install_8.patch | 2.92 KB | havran |
#7 | system.install_7.patch | 2.86 KB | havran |
#3 | system.install_6.patch | 2.86 KB | havran |
Comments
Comment #1
havran CreditAttribution: havran commentedHere is patch for this issue.
Comment #2
webchickYou need to create an update as well, for old installations.
Also, please don't mark your own patches "ready to be committed." They need community review.
Comment #3
havran CreditAttribution: havran commentedSorry. Ok i created update function (i look in function system_update_173() which is similar). Please check this. For my installation working ok, but i have only one record in files table (and file_revisions table).
Comment #4
pwolanin CreditAttribution: pwolanin commentedDo you need to copy and recreate the table, rather than just doing an update for this one column definition?
Comment #5
havran CreditAttribution: havran commentedI have PostgreSQL version 7.4. In PostgreSQL version < 8 there is no query like ALTER TABLE table ALTER COLUMN column TYPE newtype.
Comment #6
havran CreditAttribution: havran commented(ups i use >)
I have PostgreSQL version 7.4. In PostgreSQL version lower than 8 there is no query for altering column type.
Comment #7
havran CreditAttribution: havran commentedStill same bug in 5.0-beta2. Patch attached.
Comment #8
havran CreditAttribution: havran commentedAnd now i have found same bug here http://drupal.org/node/97726?
Comment #9
havran CreditAttribution: havran commentedI realise, we don't need any table operation on MySQL on this update. Modified patch attached.
Comment #10
chx CreditAttribution: chx commenteduh huh. what about adding a fid_serial column instead , then UPDATE so that fid_serial equals fid , then dropping fid columnd and renaming fid_serial finally to fid? At the end, you likely will want to VACUUM ANALYZE the poor table but still I would find this better than copying the whole thing around a few times.
Comment #11
havran CreditAttribution: havran commented(I use PostgreSQL 7.4)
For recreate fid as serial i must use:
If column fid exists as serial i give error (i think it is possible). This is not very good. May i try drop
drupal_files_fid_seq
after droping previous fid column? I think recreate table through temporary table is simpler, safer and cleaner way for this job. And if i use transaction, there is no possibility for destroy {files} data. Maybe someone create better code?Any other opinions?
Comment #12
havran CreditAttribution: havran commentedFor safer execution I added TRANSACTION in patch. I have tested it on my installation without problem.
Comment #13
sammys CreditAttribution: sammys commentedOk... seems there is a lot of action going on in here. The patch is incorrect as the CHECK condition tests the nid field rather than fid. Another thing is that we're not supplying update code for this because 4.7 already has the serial column. Update code is, after all, making a transition from 4.7 to 5.0 and not 5.0 beta to 5.0 release.
Attached is the replacement patch for system.install. This is RTBC.
As for all you wonderful people out there using the beta release, please use the manual update SQL provided in this issue to update your {files} table.
--
Sammy Spets
Synerger
http://synerger.com
Comment #14
sammys CreditAttribution: sammys commentedOh and thank you for getting to the root of the problem. I screwed up in migrating the code across because I used the MySQL schema and mapped it over to PostgreSQL. There is no mention in there about the sequence needed for files table so it was stuffed. Apologies for the inconvenience.
Comment #15
sammys CreditAttribution: sammys commentedOne other thing while i'm here. The way you guys are deleting all entries from files and file_revisions may work, but it's only half the picture because node and node_revisions tables have entries in them as well. May I suggest using something like:
Please take a backup of the files and file_revisions tables before performing these queries as i've only tested it with a small number of entries.
You shouldn't have too many entries in there anyway since the PRIMARY KEY constraint would have stopped you from having more than one fid == zero entry.
Cheers,
-- sammys
Comment #16
sammys CreditAttribution: sammys commentedDuplicate issues:
http://drupal.org/node/97726
http://drupal.org/node/100486
RTBC so let's go! :)
Comment #17
Dries CreditAttribution: Dries commentedCommitted to CVS HEAD. Thanks.
Comment #18
(not verified) CreditAttribution: commented