[01:24] sdboyer: mikey_p: something that's been nagging at me for a while but i keep forgetting. wonder if you might be able to touch up the logic that generates the commit credit list in a user's profile to exclude sandboxes on which the person is not a maintainer
[01:24] sdboyer: otherwise...Dries is gonna have a lot of commits :)

Comments

mikey_p’s picture

Assigned: Unassigned » mikey_p
Issue tags: +git phase 2
StatusFileSize
new1.49 KB

So here's the query that I came up with, not sure if it's ideal:

SELECT DISTINCT(vcp.nid), n.title, COUNT(o.vc_op_id) AS commits FROM versioncontrol_operations o INNER JOIN versioncontrol_project_projects vcp ON vcp.repo_id = o.repo_id INNER JOIN node n ON n.status = 1 AND n.nid = vcp.nid INNER JOIN project_projects pp ON n.nid = pp.nid WHERE o.author_uid = 1 AND (pp.sandbox = 0 OR (pp.sandbox = 1 AND n.uid = 1)) GROUP BY vcp.nid, n.title ORDER BY commits DESC

Here's the explain when run on git-dev.drupal.org:

mysql> EXPLAIN SELECT DISTINCT(vcp.nid), n.title, COUNT(o.vc_op_id) AS commits FROM versioncontrol_operations o INNER JOIN versioncontrol_project_projects vcp ON vcp.repo_id = o.repo_id INNER JOIN node n ON n.status = 1 AND n.nid = vcp.nid INNER JOIN project_projects pp ON n.nid = pp.nid WHERE o.author_uid = 1 AND (pp.sandbox = 0 OR (pp.sandbox = 1 AND n.uid = 1)) GROUP BY vcp.nid, n.title ORDER BY commits DESC;
+----+-------------+-------+--------+-----------------------------------------------------------------------------------+------------+---------+-------------------+-------+---------------------------------+
| id | select_type | table | type   | possible_keys                                                                     | key        | key_len | ref               | rows  | Extra                           |
+----+-------------+-------+--------+-----------------------------------------------------------------------------------+------------+---------+-------------------+-------+---------------------------------+
|  1 | SIMPLE      | o     | ref    | repo_id,author_uid                                                                | author_uid | 4       | const             | 17250 | Using temporary; Using filesort | 
|  1 | SIMPLE      | vcp   | ref    | PRIMARY,repo_id                                                                   | repo_id    | 4       | git_dev.o.repo_id |     1 | Using index                     | 
|  1 | SIMPLE      | pp    | eq_ref | PRIMARY                                                                           | PRIMARY    | 4       | git_dev.vcp.nid   |     1 | Using where                     | 
|  1 | SIMPLE      | n     | eq_ref | PRIMARY,uid,node_status_type,nid,tracker_user,tracker_global,node_status_type_uid | PRIMARY    | 4       | git_dev.vcp.nid   |     1 | Using where                     | 
+----+-------------+-------+--------+-----------------------------------------------------------------------------------+------------+---------+-------------------+-------+---------------------------------+
4 rows in set (0.00 sec)
mikey_p’s picture

Status: Active » Needs review

status

johnalbin’s picture

Dries is up 19,000 commits already. He's gonna be a 837 on CTR by Drupalcon. ;-)

http://drupal.org/user/1

dww’s picture

It's both possible and likely that people will give out "write to VCS" access to other people who want to collaborate together on a sandbox. So we should probably be checking that, too. Unfortunately, there's no way to really do that in a query, since we don't have a separate mapping table for uid/nid maintainer status. versioncontrol_project is just directly adding/removing folks from the VCAPI repo auth handler plugin. That makes sense (since we don't have to keep these things in sync) but it makes is tricky/impossible to do get this query right without a huge headache.

Not sure exactly what to do here. I guess the uid=%d check from #1 is a good first step, so I'm going to leave #1 at needs review, but I wanted to raise this before calling this fixed... ;)

mikey_p’s picture

Well there are some other problems with this listing if we want to fix it up right while we're at it, namely that it isn't paged and for folks like dww, and a few others it's quite slow to load. I'd really like to see this be a short list of top 100 maybe, with more link linking off to another paged view of projects (maybe load the more by ajax?).

Given how slow this query is we should also maybe think about caching similar to the maintainers block as well?

mikey_p’s picture

Status: Needs review » Fixed

Committed.

dww’s picture

This should have been tagged "needs drupal.org deployment", but if it was, I'd remove that tag now since this is live:

http://drupal.org/user/1

Yay. ;)

Thanks,
-Derek

Status: Fixed » Closed (fixed)
Issue tags: -git phase 2 leftovers

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