Drupal.org is running this module, thus we need it to port Drupal.org to D7.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

webchick’s picture

Issue tags: +project, +drupal.org D7, +testbot, +porting

Tagging.

webchick’s picture

Title: Port to Drupal 7 » Port Project Dependency to Drupal 7

Fixing title.

jojonaloha’s picture

Attached is a coder_upgrade port of this module, untested and incomplete, but a start. This also has a dependency on #1551384: Port project_release to D7

jthorson’s picture

I just generated a (completely untested) 6.x->7.x coder_upgrade run, and pushed it to the 7.x-1.x branch in the repository.

rfay’s picture

Just about to do a new release though... Not sure how much value a straight port is going to be until we see what comes of Project module.

dww’s picture

Project module itself is pretty much ported. Mostly true of project_release, too. The biggest changes from D6 are:

A) There's no hard-coded project_project node type anymore. Any node type can be configure to be a project. So, for d.o we're going to have separate node types for the different kinds of project nodes (modules, themes, distros, etc).

B) There are no custom fields, it's all just core field API.

I don't think anything else that would impact project_dependency has really changed at all. project_release was more of a straight port from D6 than I was hoping for, but that's probably better as far as project_dependency is concerned. Certainly nothing fundamental has changed in terms of multiple modules being packaged together in a single project or version numbers, etc. Those are decisions the community makes and then Project* is reconfigured or rewritten to handle the change.

Feel free to put questions about D7 Project* and how it relates to project_dependency here and I'll do my best to answer quickly.

Cheers,
-Derek

rfay’s picture

PD currently relies on custom queries of project release, project, and node. Will have to figure out what the correct replacements of those are.

I've asked @trobey if he might consider doing the D7 port.

rfay’s picture

I guess the first question, @dww, is how do we get a populated Drupal.org database with D7 that has all projects and such in it. It will be all theoretical without that. Is there a db we can use on util in /var/backups/mysql?

jthorson’s picture

I've corrected all the function calls to project_get_nid_from_uri() to use the new project_get_nid_from_machinename() function, and adjusted all the database statements to get rid of periods inside the placeholders ... drush pdsd, pdpv, and pdpp all now execute without throwing PHP or PDO errors.

I suspect the queries will still need to be adjusted, and a strategy for loading the database information to fully test things out ... as I'm currently getting obviously incorrect outputs:

Processing dependencies for views
Skipped (or git failed) views: 1
Skipped (or git failed) views: 7
Skipped (or git failed) views: 7

In any case, the light lifting has been completed (in the 7.x-1.x branch), and all that should be left are the logic corrections due to changes in Project*.

jthorson’s picture

Issue tags: -project, -testbot, -porting

One area that I wasn't 100% sure about ... this could definately use some scrutiny:

/**
 * Attempt to determine the Drupal core API term.
 *
 * @param $node
 *   Node object.
 *
 * @return
 *   Core API term to which the node belongs, otherwise FALSE.
 */
function project_dependency_info_core_api($node) {
  return project_release_get_release_api_tid($node);   // <---- Added to replace existing function

  /*  TODO:  Old D6 version code below - is the above function equivalent?
  static $api_terms = array();

  if (empty($node->nid)) {
    return NULL;
  }
  if (empty($api_terms[$node->nid])) {
    $api_terms[$node->nid] = FALSE;

    if (!empty($node->taxonomy)) {
      // Relase API version vocabulary.
      $api_vid = _project_release_get_api_vid();

      foreach ($node->taxonomy as $tid => $term) {
        if ($term->vid == $api_vid) {
          $api_terms[$node->nid] = $term;
        }
      }
    }
  }
  return $api_terms[$node->nid];
  */
}
jthorson’s picture

Issue tags: +project, +testbot, +porting

Replacing tags ...

rfay’s picture

jthorson++

dww’s picture

git7site.devdrupal.org is being rebuilt daily with a full DB snapshot and being migrated to D7. At this point, drumm and sdboyer know much more about how all that's working than I do, and could probably help you get access to a DB snapshot or something.

All that evil API compatibility taxonomy crap from D6 has survived in the D7 port. That's bad news for me, but good news for you. ;) I think #10 is basically right, yeah. project_release_get_release_api_tid() in D7 appears to be doing what you need.

Thanks for moving this forward!

Cheers,
-Derek

jthorson’s picture

I assumed that the reason I was receiving empty array() results for project_dependency_show_dependencies() was because the underlying database tables were not datafilled. This was incorrect ... the tables are there and datafilled. This means there is no need to run the pre-populate routine, and we shouldn't end up eating up Gigs of disk space on the dev server.

It also means that the issue lies somewhere in the code.

jthorson’s picture

Added a few more fixes to the D7 port ... next outstanding issue is the query at line 105 of project_dependency.drupal.inc references the {taxonomy_term_node} table, which does not exist.

jthorson’s picture

Fixed some additional queries, and did a bunch of array-to-object conversions to handle the PDO queries shipping back object results instead of arrays.

project_dependency_show_dependency() now appears to be spitting out results, though it could use some testing to confirm that they are actually accurate. I ended up dropping a sort off the end of a query due to that column no longer existing (vid in term_node is not present in the new taxonomy_index table); which could potentially affect the dependency calculation.

Edit: The dependency processing side still needs some attention.

jthorson’s picture

I think the 7.x-1.x branch is now working correctly. Here is the complete port.

jthorson’s picture

Status: Active » Needs review
Senpai’s picture

Version: 6.x-1.x-dev » 7.x-1.x-dev
Assigned: Unassigned » boombatower
Priority: Normal » Major
Issue tags: +4hr

Estimating at 4hr worth of work left, assuming this patch is good. Assigning to @boombatower for review.

jthorson’s picture

Assigned: boombatower » rfay

Boombatower took a look at this during BADCamp ... bumping to Randy, who I believe was loading up a D7 database in order to look at it tonight as well.

rfay’s picture

Sadly, I'm still waiting on the load. The db is 40GB now... it filled up my mac's drive, so started over on a linux machine with more disk. But oh so slow. Odd. I don't understand why the d7 db would be so dramatically big compared to d6.

rfay’s picture

Finally done... 64GB of database. Wow. I'll try to look at it tomorrow afternoon or on the weekend.

jthorson’s picture

Just a guess, but it may be tables for the migration which are making your database so large. I got caught while working on PIFT, writing queries against tables which should disappear in D7, but still existed in my D7 dev site.

jthorson’s picture

Some additional port fixes ... mostly related to query results showing up as objects instead of arrays.

rfay’s picture

Please open new issues... and since I'm working on this all day and trying to merge the later 6.x issues in, it would be better to wait.

As always, thanks for all your work on this.

I'll try to apply this...

rfay’s picture

Committed #24 in 2c84a01

boombatower’s picture

If I remember correctly it seemed there was an issue with newlines and such in queries that can arise...or just a general best practice to use string concatenation, perhaps I am mistaken.

+  return db_query('
+    SELECT * FROM {project_dependency_component}
+    WHERE component_id = :component_id',
+    array(':component_id' => $component_id),
+    array('fetch' => PDO::FETCH_ASSOC)
+  );
rfay’s picture

Status: Needs review » Fixed

IMO this is ready to go. I fixed a number of bugs and worked with a number of standard cases and verified the results. Also applied the outstanding patches from the 6.x-1.x branch.

I reviewed the diff of all the changes, and saw no red herrings.

Thanks for all the great work on this, @jthorson.

rfay’s picture

Created release 7.x-1.0-alpha1

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