So I'm currently working on the View integration issue, and one of the sub-tasks is the Platform view. One of the fields for the view is the 'Release' field.

Currently the 'release' key is being attached to the $node object via a series of joins between multiple tables and a node load, however there is a 'release_id' field in the 'hosting_platform' table which is going completely unused.

The reason I mention these two things is that if the 'release_id' field was used, and potentially the source instead of the series of joins and node load, it would allow an extremely simply relationship to be added for Views, however currently that is not the case and I suspect allowing the Release node to be exposed to the view as a relationship is going to be somewhat painful.

I'm curious on why the field is defined in the schema and not used, if someone had intended to add it or was in the process of removing it, and if there is any backstory on it before I make a decision on how best to proceed.

Files: 
CommentFileSizeAuthor
#4 remove-release-id.patch862 byteschertzog

Comments

Digging around a bit, it looks like 'release_id' has been with us since the Drupal 5 days. But then hosting_package_update_5() appears to drop it, but it never got removed from the schema definition. This appears to have been an oversight, probably due to the schema bit being in a different module.

AFAICT, that function was added in http://drupalcode.org/project/hosting.git/commit/5da33dbe238ac710e1cad6c..., which in turn references: #416550: Denormalize package handling node types. Comment #1 mentions the 'release_id' column, and it's being replaced with a 'hosting_package_instance'.

As far as the Views go, could we maybe leverage a relationship with the hosting_package_instance to determine the release? Otherwise, perhaps we could use the release_id field, but presumably we'd have to keep it in sync with the hosting_package_instance anyway.

I think this should be removed. Now, this seems tricky since it *could* be in some installs and not others so we can't just blindlessly drop the column: we need to not fail if it is absent.

Otherwise: go.

Priority:Normal» Minor

From a customisation point of view, having the column available would allow for a super simple relationship in Views so that the end users could configure the look and display of the Release column as they want, however, to do that the field would have to be in use, and it would actually have to reference the Release IID not the Release ID.

I've submitted my patch to just use a dumb field for the Release column at #1876350: Convert list of platforms to use views, so this is a fairly minor issue now and I wouldn't be too upset if the column went away, but there is definitely a benefit of it being re-instated.

Status:Active» Needs review
StatusFileSize
new862 bytes

Here is a patch to update the schema, and drop the field if it exists.

Status:Needs review» Fixed

merged in 2.x and 3.x. updated the upgrade notes.

http://community.aegirproject.org/upgrading/path

Status:Fixed» Closed (fixed)

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