Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
Drupal.org is running this module, thus we need it to port Drupal.org to D7.
Comment | File | Size | Author |
---|---|---|---|
#24 | project_dependency_port_fixes-24.patch | 2.07 KB | jthorson |
#17 | Project_Dependency_D7_Port_do_not_test.diff | 22.16 KB | jthorson |
#3 | project_dependency-1465786-port_d7.patch | 16.23 KB | jojonaloha |
Comments
Comment #1
webchickTagging.
Comment #2
webchickFixing title.
Comment #3
jojonaloha CreditAttribution: jojonaloha at Metal Toad commentedAttached 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
Comment #4
jthorson CreditAttribution: jthorson commentedI 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.
Comment #5
rfayJust 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.
Comment #6
dwwProject 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
Comment #7
rfayPD 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.
Comment #8
rfayI 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?
Comment #9
jthorson CreditAttribution: jthorson commentedI'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:
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*.
Comment #10
jthorson CreditAttribution: jthorson commentedOne area that I wasn't 100% sure about ... this could definately use some scrutiny:
Comment #11
jthorson CreditAttribution: jthorson commentedReplacing tags ...
Comment #12
rfayjthorson++
Comment #13
dwwgit7site.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
Comment #14
jthorson CreditAttribution: jthorson commentedI 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.
Comment #15
jthorson CreditAttribution: jthorson commentedAdded 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.
Comment #16
jthorson CreditAttribution: jthorson commentedFixed 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.
Comment #17
jthorson CreditAttribution: jthorson commentedI think the 7.x-1.x branch is now working correctly. Here is the complete port.
Comment #18
jthorson CreditAttribution: jthorson commentedComment #19
Senpai CreditAttribution: Senpai commentedEstimating at 4hr worth of work left, assuming this patch is good. Assigning to @boombatower for review.
Comment #20
jthorson CreditAttribution: jthorson commentedBoombatower 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.
Comment #21
rfaySadly, 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.
Comment #22
rfayFinally done... 64GB of database. Wow. I'll try to look at it tomorrow afternoon or on the weekend.
Comment #23
jthorson CreditAttribution: jthorson commentedJust 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.
Comment #24
jthorson CreditAttribution: jthorson commentedSome additional port fixes ... mostly related to query results showing up as objects instead of arrays.
Comment #25
rfayPlease 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...
Comment #26
rfayCommitted #24 in 2c84a01
Comment #27
boombatower CreditAttribution: boombatower commentedIf 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.
Comment #28
rfayIMO 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.
Comment #29
rfayCreated release 7.x-1.0-alpha1