No *old* comment uploads shown after 5.12 -> 6.6 upgrade

It's because of drupal_write_record('comment_upload', $file); in *.install file.
A scheme 'comment_upload' is not available during the process.
Moreover using drupal_write_record() in install is not good (Updating tables #2: Don't use hook_schema!, thanks Gabor for pointing out). update_sql() is more proper solution.

So the patch fixed it.

Not sure I should escape variables in sql queries.

Good catch. Some notes:

- db_drop_table() should be fine to use in an update function, it just does a DROP TABLE
- everything but the description is an INT, so they would not need escaping, the description however would need it... since update_sql() lacks support for %s type of placeholders, you'd need to use db_escape_string() there

Otherwise looks good.

Excellent.

On using db_query: I'd hesitate to pollute the update log with these queries. If the queries somehow fail, they cannot be manually executed due to fid.

I've also added the missing status so cron doesn't wipe out the files the next time it is run (timestamp = 0).

I applied the patch to an update from 6.5 to 6.6 and it didn't resolve my issue.

uploaded files on comments had ceased working at some point after initial installation into 6.3, either with upgrade to 6.4 or 6.5.

behavior is that the file is created in the location specified in file uploads, and is added to the files table, NOT to the comment_upload table. it's like it has become a broken version of uploads.

I applied patch in #4 but disabling/enabling module did nothing, so I forced an update on 6001, then back to update 1, with no change either time.

it seems comment_upload was missing nid column. at least I hope that's all that's wrong.

I manually added field `nid` int(10) unsigned NOT NULL default '0' to comment_upload table, and successfully uploaded a file to a comment.

it doesn't look like there was a nid column in the install file in 6.x-1.5dev which is where I started, so it's no surprise I got the following errors trying to update from where I was:

* user warning: Table 'pdxindie.comment_files' doesn't exist query: ALTER TABLE comment_files ADD nid int NOT NULL default '0' in /www/pdxindie.com/subdomains/www/modules/comment_upload/comment_upload.install on line 94.
* user warning: Table 'pdxindie.comment_files' doesn't exist query: SELECT c.cid, c.nid FROM comments c WHERE c.cid IN (SELECT DISTINCT cf.cid FROM comment_files cf) in /www/pdxindie.com/subdomains/www/modules/comment_upload/comment_upload.install on line 97.
* user warning: Table 'pdxindie.comment_files' doesn't exist query: SELECT MAX(fid) FROM comment_files in /www/pdxindie.com/subdomains/www/modules/comment_upload/comment_upload.install on line 125.
* user warning: Table 'pdxindie.file_revisions' doesn't exist query: SELECT f.fid, cf.nid, cf.cid, cf.cid, f.filename, f.filepath, f.filemime, f.filesize, r.list, r.description FROM files f INNER JOIN file_revisions r ON f.fid = r.fid INNER JOIN comment_files cf ON f.fid = cf.fid WHERE f.nid = 0 in /www/pdxindie.com/subdomains/www/modules/comment_upload/comment_upload.install on line 126.
* user warning: Unknown table 'comment_files' query: DROP TABLE comment_files in /www/pdxindie.com/subdomains/www/modules/comment_upload/comment_upload.install on line 136.
* user warning: Table 'comment_upload' already exists query: CREATE TABLE comment_upload ( `fid` INT unsigned NOT NULL DEFAULT 0, `nid` INT unsigned NOT NULL DEFAULT 0, `cid` INT unsigned NOT NULL DEFAULT 0, `description` VARCHAR(255) NOT NULL DEFAULT '', `list` TINYINT unsigned NOT NULL DEFAULT 0, `weight` TINYINT NOT NULL DEFAULT 0, PRIMARY KEY (fid), INDEX cid_fid (cid, fid), INDEX nid (nid) ) /*!40100 DEFAULT CHARACTER SET UTF8 */ in /www/pdxindie.com/subdomains/www/includes/database.inc on line 515.

@miahawk: the issue fixed by the patch was in the Drupal 5 -> 6 upgrade. Re-running that upgrade on a site already updated to Drupal 6 could easily lead to unintended consequences and errors as it probably happened to you. You should run the upgrade code on your Drupal 5 backup and check out the results. It certainly worked for Vladimir above. I doubt that there is such a serious issue there as a missing nid column, and expect that you experienced that due to running an older update function then what state your database was in.

no, my site started at 6.3, it never was on 5.x. but, the installer for 6.x-1.5-dev dated 2008/07/30 did not include the nid column, so when I upgraded to the latest dev version, comment upload probably just simply ceased to work because the nid column wasn't added.

the failure alerts indicate that the database table wasn't changed except for the last 6001 update, so I'm not too concerned about changes made during that process, more about what else may have failed to update that I need, just because I didn't start with 5.x so tables weren't modified when I upgraded the mod. after looking through the installer, it just looks like there wasn't a provision to add the nid column unless one did start from 5.x or removed the mod and reinstalled, but since I started with a previous 6.x version that didn't include the nid column in the installer, it was never added. it's possible I missed something in the code since I'm not a programmer, but that's what looks like happened.

so really, I was simply giving feedback on the patch since I did use it to try to resolve similar behavior, but I think I should probably opened a support request specifically addressing upgrades from previous 6.x dev versions. my purpose was only to report my findings because I think others who initially installed a previous version of comment upload for 6.x might encounter the nid column issue.

it is really an awesome mod so I'm glad I figured out I needed to get the nid added so that it works again. I'm just hoping that's all that's missing.

@miahawk: well, you used a 6.x-dev version, which is considered unsupported in Drupal-land. Next time please comment on relevant issues. This issue is about the 5.x supported -> 6.x upgrade path, not upgrade path from an unsupported 6.x-dev to another 6.x version. It would be good to not hold up a good patch when you have unrelated problems.

yes, you are right. I thought it was similar at first, because of the behavior, but it was where I started (6.x dev) that was the issue. I'd really only wanted to get the information out so it might help someone else, but like I said I should have opened a support request and answered my own question.

I really wasn't trying to hold up a patch, sorry. I didn't see at first it was a 5.x upgrade path issue.

I've applied the patch in #4