Related Issues

This issue is blocking #1606656: Port the 'project_release_download_base' setting to D7 and make it per-node-type's creation of a field formatter.

Problem/Motivation

Splitting off from #1551384: Port project_release to D7 ...

As I'm porting, there's a fair bit of D6 code in project_release to add custom "fields" to each file associated with a release. The prime example is the md5 hash, but there's also the download count and weight (relative to other files). From what I can tell, D7 doesn't make this particularly easy if we're just using a core file field on release nodes (which is what we want).

We can use a field_collection to represent each file associated with a release. This seems like a fairly straight-forward and natural fit. The files attached to a release are actually represented by a multi-valued field_collection. These field collection entities (that's how field_collection works) would have a single-valued file field, and separate fields (definable via the UI, in fact) for everything we care about md5 hash, download count, a sha1 hash if we wanted to add that, etc.

Comments

Dave Reid’s picture

Dave Reid
he/him
Primary language English
Location Nebraska USA
CreditAttribution: Dave Reid commented

So I think you've hit the nail on the head for the two solutions here.

The biggest use case for file_entity (aside from also getting the benefit of Media) is to have user-editable data about files appear wherever that file is used (and files should be intended to be re-used).

To me this seems like a good use case for Field collection. Weight can be expressed using the field delta value (and shouldn't need it's own field). MD5 hash I assume is not something that is user-entered so I wouldn't think it's even a field. Download count as well I would assume is meta data about a file and not something that is field-oriented. So maybe you don't even need Field collection nor File entity at all?

dww’s picture

dww
we/he/they
CreditAttribution: dww commented
Assigned: Unassigned » dww

Well -- just because it's not user-entered doesn't mean it shouldn't be a field. There's a hidden widget, after all. ;) However, if they're fields:

  • We don't have to worry about storage.
  • We don't have to worry about telling Views about them.
  • Sites can define other stuff they care about easily. For example, we might want a "variant" flag on d.o for distro releases (which we hack now via "-core", "-no-core" etc just in the filename). Maybe we want a sha1 hash (or not). Maybe some site is selling releases and needs to add a price field or something wonky. I dunno. ;)

So yeah, seems like field_collection is the right answer here. And I'll just put it into the default node type we ship, but it'll be easy for folks to extend this if they care.

Thanks for the feedback!
-Derek

Dave Reid’s picture

Dave Reid
he/him
Primary language English
Location Nebraska USA
CreditAttribution: Dave Reid commented

Could we abstract download counting into something that works for all files? How are download counts generated?

drumm’s picture

drumm
he/him
Location NY, US
CreditAttribution: drumm commented

Dave Reid - download counts are a bit of a contraption for Drupal.org. There are Jenkins jobs which collect and parse Awstats data. The parsing is http://drupalcode.org/project/drupalorg.git/blob/refs/heads/7.x-3.x:/dru.... We previously found that click tracking severely undercounted downloads and we already have Awstats summarizing log data from all our web servers. It isn't pretty, but it counts downloads.

drumm’s picture

drumm
he/him
Location NY, US
CreditAttribution: drumm commented
Assigned: dww » drumm

Seems like the consensus is B) field_collection. I'll go ahead and update the issue summary and see what I can do.

drumm’s picture

drumm
he/him
Location NY, US
CreditAttribution: drumm commented
Issue summary: View changes

This issue is blocking #1606656: Port the 'project_release_download_base' setting to D7 and make it per-node-type's creation of a field formatter.

drumm’s picture

drumm
he/him
Location NY, US
CreditAttribution: drumm commented

I committed the fields and collection, http://drupalcode.org/project/project.git/commit/1e0a2df. Now on to calculating MD5s and everything else.

drumm’s picture

drumm
he/him
Location NY, US
CreditAttribution: drumm commented

The MD5 is being updated now. I opted to just always calculate all the MD5s, I didn't see a quick way to detect if a file was replaced.

Now I'm going through various places files are used. In particular, should we stick with custom theme functions, like project_release_download_table_row or try out http://drupal.org/project/field_collection_table?

hswong3i’s picture

hswong3i CreditAttribution: hswong3i commented

Sorry please kindly correct me if not related to this issue: When using git_deploy + GIT submodule (e.g. https://github.com/pantarei/pantarei-drupal/tree/7.15pantareiY/sites/all...), it is difficult for us to figure out if remove -dev package correctly generated as like as local latest HEAD hash (see #1254200: Fix dev release time) in "Available updates" report page.

My suggestion is to add the commit SHA1 hash to the release history XML output (e.g. http://updates.drupal.org/release-history/git_deploy/7.x) so git_deploy can alter based on this SHA1, as patrick2000's comment on http://drupal.org/node/1254200#comment-4902178.

Any idea?

drumm’s picture

drumm
he/him
Location NY, US
CreditAttribution: drumm commented

hswong3i - yes, that is unrelated. #914284: Update packaging scripts to create some sort of MANIFEST may be what you are looking for.

drumm’s picture

drumm
he/him
Location NY, US
CreditAttribution: drumm commented
Status: Active » Fixed

Now that the 1551384-release-deep-port branch is merged, and all the data storage and a lot of the UI is moved, I'm calling this fixed.

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

(not verified) CreditAttribution: commented
Issue summary: View changes

Paring down options since we have a plan.