While writing the other side of the new package detection code (http://drupal.org/node/368294), I realized that we would be better served by denormalizing the package and package release stuff.

We have a separate table just to store the version number and schema version number. It's pretty simple to just add these fields to the package instance, which
A) drastically reduces the node count on the site
B) drastically reduces the complexity of the queries we need to write (we don't have to join through a separate node type).
C) drastically reduces the code related to package handling (hosting_package.module currently has 2 complete node types, and we only need half the code)

Since this is mostly just removing code, i'm going to be doing this as I do the import code, since it doesn't make sense to write all the super complex code just to remove it afterwards.

Comments

adrian’s picture

adrian commented

This seems to be working out very well, and is going to save us from doing some crazy code.
Another side effect of this is we are getting rid of a bunch of columns on sites and platforms.

Instead of having an explicit 'release_id' column in hosting platform, and having an explicit 'profile' column for the site, it will now have a 'hosting_package_instance' of the profile and drupal release associated to it.

I've also added some of the columns I've been meaning to add to the instance table such as 'status' (to track which modules/themes are enabled)

This also makes http://drupal.org/node/319270 easier and it might also be the first step towards #344967 (code cleanup wise, since some of the patterns are similar)

the other issue is still out of bounds till 0.3, but at least we're going to have somewhat similar code to base things off of.

adrian’s picture

adrian commented
Status: Active » Fixed

committed.

but i might have introduced some bugs, new tickets should be opened for them.

Status: Fixed » Closed (fixed)

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