add 'module' column to files table

big +1

i had proposed this (which i can't find now - perhaps it was in irc or conversation with dries) - when I first rewrote image.module.

i love the "domain" idea ... i.e. image.module can use it to keep track of "image_thumbnail" ... etc. (rather than the file name hack now).

Yes, I think that would be very usefull.

[null comment so I get subscribed to this issue...]

I would like to see this (+1) and I suggest the column be named 'realm' to follow the example set in the node_access table.

i'd suggest it be named 'module' to follow the, i believe more relevant, prescient set in the taxonomy module.

here's a patch that adds the field. it assumes that all existing files are owned by the upload module. other modules will need to assert ownership as part of their updates.

currently, to avoid having the upload module display other module's attached files, they'll either do some form_alter hackery to remove them or not put a record into file_revisions.

on IRC, gatsby pointed out that there should be an index on module.

While the gain is only obvious to those who run contrib modules that's no reason to not get this in when it means no harm for core. So, let's rock!

IMO, that should be a composite primary - fid, module. From a quick browse of the queries in upload module, there should also be a separate index for module.

There are also a number of other queries that need to be updated. The DELETE queries and the SUM queries all need to be filtered on module name. I also noticed that the table is missing an index for filepath. Perhaps this can be included in this patch and sorted in one update - something like filepath (64) should do, methinks.

-K

Patch re-rolled as above. I'm not really familiar with the upload module. Please review with care. Additionally, please review the pgSQL queries as they have not been tested at all.

-K

i don't think the primary key should be on (fid, module), fid was fine but there should be a joint key on nid, module. that's what the majority of the queries match for. i also removed the 'upload' default.

attached patch corrects some inconsistencies in the db schema for this change. indexes were inconsistent, and a pg statement was failing on upgrade. i tested both a clean install and a 5 -> 6 upgrade for both mysql and pgsql, and all are working perfectly now.

also made some small changes in the quote usage -- i think it's more consistent w/ core to use double quotes when there are single quotes inside, instead of \ escaping them.

Tested on a clean 6.x install (MySQL), core upload.module seems to be working correctly.

There are some notices from upload.module, but they appear to be unrelated to the patch and should probably be fixed in a separate issue.

Tested the upgrade path, tested adding, editing, de-listing, and deleting files with upload.module. All seems to work properly. As webernet pointed out, there are notices, but they're there even when the patch is reverted, and can be cleaned up post-code freeze.

RTBC.

just in case this change needed any more justification i wanted to point to this issue as an example of why it's needed. the image module ends up deleting files attached to the node by other modules because there's not an easy way to tell who put which record there.

here's a re-roll post schema patch.

#115267 got committed and broke this. i need to spend a little time figuring out how the two will work together.

Folks interested in this issue, I recommend you look at http://drupal.org/project/upapi for your module development needs.

how about storing the $file->source data instead of module name? This way, a module can do file categorization within its files.

ufku, i don't think i understand what would be done with $file->source? that's only used during the initial upload processing... module's can categorize files by the file's id. the problem is knowing who's file it is.

Based on the new file system(6.x):
i mean source is alrady there(file_save_upload) as a file property. modules can define unique source strings(module name or whatever they want) for them.
let file_save_upload store it.

Advantage of custom strings: a module can define more than one identifying string for itself or more than one module can define a common string.

Advantage of forcing module name as identifying string: moduleX can get the files of moduleY without the need for knowing Y's identifying strings.

this is what i meant. i hope it has something to do with the initial topic:)

I've come back to the conclusion that we do need this if only for doing private file previews. In that case the module hasn't stored any info about the file and at that point is only given the filepath. Often that's not even enough information for the originating module to say that yes that's my file and downloads should be allowed. With the module column as a record of the file's originator the module could do something like grant access to all temp files it's originated.

i think that #353458: hook_file_references() was not designed for a highly flexible field storage might be a good solution for this.

No support for postgress in ad_weight_probability. Any tutorial or table listing for the add module?

This issue is about adding a module column to the {files} table, the ad module is a different project with it's own issue queue.

I believe that this issue is now moot, with file_usage in place for some time.