1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-11-29 10:12:41 +01:00
phorge-phorge/src/applications/differential/controller/DifferentialRevisionListController.php

503 lines
15 KiB
PHP
Raw Normal View History

2011-01-26 00:19:06 +01:00
<?php
/*
* Copyright 2012 Facebook, Inc.
2011-01-26 00:19:06 +01:00
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
final class DifferentialRevisionListController extends DifferentialController {
2011-01-26 00:19:06 +01:00
2011-01-27 20:35:04 +01:00
private $filter;
private $username;
2011-01-27 20:35:04 +01:00
public function shouldRequireLogin() {
return !$this->allowsAnonymousAccess();
}
2011-01-27 20:35:04 +01:00
public function willProcessRequest(array $data) {
$this->filter = idx($data, 'filter');
$this->username = idx($data, 'username');
2011-01-27 20:35:04 +01:00
}
2011-01-26 00:19:06 +01:00
public function processRequest() {
$request = $this->getRequest();
$user = $request->getUser();
$viewer_is_anonymous = !$user->isLoggedIn();
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
$params = array_filter(
array(
'status' => $request->getStr('status'),
'order' => $request->getStr('order'),
));
$default_filter = ($viewer_is_anonymous ? 'all' : 'active');
$filters = $this->getFilters();
$this->filter = $this->selectFilter(
$filters,
$this->filter,
$default_filter);
// Redirect from search to canonical URL.
$phid_arr = $request->getArr('view_user');
if ($phid_arr) {
$view_user = id(new PhabricatorUser())
->loadOneWhere('phid = %s', head($phid_arr));
$base_uri = '/differential/filter/'.$this->filter.'/';
if ($view_user) {
// This is a user, so generate a pretty URI.
$uri = $base_uri.phutil_escape_uri($view_user->getUserName()).'/';
} else {
// We're assuming this is a mailing list, generate an ugly URI.
$uri = $base_uri;
$params['phid'] = head($phid_arr);
}
$uri = new PhutilURI($uri);
$uri->setQueryParams($params);
return id(new AphrontRedirectResponse())->setURI($uri);
}
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
$uri = new PhutilURI('/differential/filter/'.$this->filter.'/');
$uri->setQueryParams($params);
$username = '';
if ($this->username) {
$view_user = id(new PhabricatorUser())
->loadOneWhere('userName = %s', $this->username);
if (!$view_user) {
return new Aphront404Response();
}
$username = phutil_escape_uri($this->username).'/';
$uri->setPath('/differential/filter/'.$this->filter.'/'.$username);
$params['phid'] = $view_user->getPHID();
} else {
$phid = $request->getStr('phid');
if (strlen($phid)) {
$params['phid'] = $phid;
}
}
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
// Fill in the defaults we'll actually use for calculations if any
// parameters are missing.
$params += array(
'phid' => $user->getPHID(),
'status' => 'all',
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
'order' => 'modified',
);
$side_nav = new AphrontSideNavView();
foreach ($filters as $filter) {
list($filter_name, $display_name) = $filter;
if ($filter_name) {
$href = clone $uri;
$href->setPath('/differential/filter/'.$filter_name.'/'.$username);
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
if ($filter_name == $this->filter) {
$class = 'aphront-side-nav-selected';
} else {
$class = null;
}
$item = phutil_render_tag(
'a',
array(
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
'href' => (string)$href,
'class' => $class,
2011-01-27 20:35:04 +01:00
),
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
phutil_escape_html($display_name));
} else {
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
$item = phutil_render_tag(
'span',
array(),
phutil_escape_html($display_name));
}
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
$side_nav->addNavItem($item);
2011-01-27 20:35:04 +01:00
}
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
$panels = array();
$handles = array();
$controls = $this->getFilterControls($this->filter);
if ($this->getFilterRequiresUser($this->filter) && !$params['phid']) {
// In the anonymous case, we still want to let you see some user's
// list, but we don't have a default PHID to provide (normally, we use
// the viewing user's). Show a warning instead.
$warning = new AphrontErrorView();
$warning->setSeverity(AphrontErrorView::SEVERITY_WARNING);
$warning->setTitle('User Required');
$warning->appendChild(
'This filter requires that a user be specified above.');
$panels[] = $warning;
} else {
$query = $this->buildQuery($this->filter, $params['phid']);
2011-01-27 20:35:04 +01:00
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
$pager = null;
if ($this->getFilterAllowsPaging($this->filter)) {
$pager = new AphrontPagerView();
$pager->setOffset($request->getInt('page'));
$pager->setPageSize(1000);
$pager->setURI($uri, 'page');
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
$query->setOffset($pager->getOffset());
$query->setLimit($pager->getPageSize() + 1);
}
foreach ($controls as $control) {
$this->applyControlToQuery($control, $query, $params);
}
$revisions = $query->execute();
if ($pager) {
$revisions = $pager->sliceResults($revisions);
}
$views = $this->buildViews($this->filter, $params['phid'], $revisions);
$view_objects = array();
foreach ($views as $view) {
if (empty($view['special'])) {
$view_objects[] = $view['view'];
}
}
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
$phids = array_mergev(mpull($view_objects, 'getRequiredHandlePHIDs'));
$phids[] = $params['phid'];
$handles = id(new PhabricatorObjectHandleData($phids))->loadHandles();
foreach ($views as $view) {
if (empty($view['special'])) {
$view['view']->setHandles($handles);
}
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
$panel = new AphrontPanelView();
$panel->setHeader($view['title']);
$panel->appendChild($view['view']);
if ($pager) {
$panel->appendChild($pager);
}
$panels[] = $panel;
}
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
}
$filter_form = id(new AphrontFormView())
->setMethod('GET')
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
->setAction('/differential/filter/'.$this->filter.'/')
->setUser($user);
foreach ($controls as $control) {
$control_view = $this->renderControl($control, $handles, $uri, $params);
$filter_form->appendChild($control_view);
}
$filter_form
->addHiddenInput('status', $params['status'])
->addHiddenInput('order', $params['order'])
->appendChild(
id(new AphrontFormSubmitControl())
->setValue('Filter Revisions'));
$filter_view = new AphrontListFilterView();
$filter_view->appendChild($filter_form);
if (!$viewer_is_anonymous) {
$create_uri = new PhutilURI('/differential/diff/create/');
$filter_view->addButton(
2011-01-27 20:35:04 +01:00
phutil_render_tag(
'a',
array(
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
'href' => (string)$create_uri,
'class' => 'green button',
2011-01-27 20:35:04 +01:00
),
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
'Create Revision'));
}
$side_nav->appendChild($filter_view);
foreach ($panels as $panel) {
$side_nav->appendChild($panel);
2011-01-27 20:35:04 +01:00
}
2011-01-26 00:19:06 +01:00
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
return $this->buildStandardPageResponse(
$side_nav,
array(
'title' => 'Differential Home',
));
}
private function getFilters() {
return array(
array(null, 'User Revisions'),
array('active', 'Active'),
array('revisions', 'Revisions'),
array('reviews', 'Reviews'),
array('subscribed', 'Subscribed'),
array('drafts', 'Draft Reviews'),
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
array(null, 'All Revisions'),
array('all', 'All'),
);
}
private function selectFilter(
array $filters,
$requested_filter,
$default_filter) {
// If the user requested a filter, make sure it actually exists.
if ($requested_filter) {
foreach ($filters as $filter) {
if ($filter[0] === $requested_filter) {
return $requested_filter;
}
2011-01-31 03:24:57 +01:00
}
}
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
// If not, return the default filter.
return $default_filter;
}
private function getFilterRequiresUser($filter) {
static $requires = array(
'active' => true,
'revisions' => true,
'reviews' => true,
'subscribed' => true,
'drafts' => true,
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
'all' => false,
);
if (!isset($requires[$filter])) {
throw new Exception("Unknown filter '{$filter}'!");
}
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
return $requires[$filter];
}
2011-01-31 03:24:57 +01:00
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
private function getFilterAllowsPaging($filter) {
static $allows = array(
'active' => false,
'revisions' => true,
'reviews' => true,
'subscribed' => true,
'drafts' => true,
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
'all' => true,
);
if (!isset($allows[$filter])) {
throw new Exception("Unknown filter '{$filter}'!");
2011-01-31 03:24:57 +01:00
}
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
return $allows[$filter];
}
2011-01-31 03:24:57 +01:00
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
private function getFilterControls($filter) {
static $controls = array(
'active' => array('phid'),
'revisions' => array('phid', 'status', 'order'),
'reviews' => array('phid', 'status', 'order'),
'subscribed' => array('subscriber', 'status', 'order'),
'drafts' => array('phid', 'status', 'order'),
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
'all' => array('status', 'order'),
);
if (!isset($controls[$filter])) {
throw new Exception("Unknown filter '{$filter}'!");
}
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
return $controls[$filter];
}
private function buildQuery($filter, $user_phid) {
$query = new DifferentialRevisionQuery();
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
$query->needRelationships(true);
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
switch ($filter) {
case 'active':
$query->withResponsibleUsers(array($user_phid));
$query->withStatus(DifferentialRevisionQuery::STATUS_OPEN);
$query->setLimit(null);
break;
case 'revisions':
$query->withAuthors(array($user_phid));
break;
case 'reviews':
$query->withReviewers(array($user_phid));
break;
case 'subscribed':
$query->withSubscribers(array($user_phid));
break;
case 'drafts':
$query->withDraftRepliesByAuthors(array($user_phid));
break;
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
case 'all':
break;
default:
throw new Exception("Unknown filter '{$filter}'!");
2011-01-31 03:24:57 +01:00
}
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
return $query;
}
2011-01-31 03:24:57 +01:00
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
private function renderControl(
$control,
array $handles,
PhutilURI $uri,
array $params) {
assert_instances_of($handles, 'PhabricatorObjectHandle');
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
switch ($control) {
case 'subscriber':
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
case 'phid':
$view_phid = $params['phid'];
$value = array();
if ($view_phid) {
$value = array(
$view_phid => $handles[$view_phid]->getFullName(),
);
}
if ($control == 'subscriber') {
$source = '/typeahead/common/allmailable/';
$label = 'View Subscriber';
} else {
$source = '/typeahead/common/accounts/';
$label = 'View User';
}
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
return id(new AphrontFormTokenizerControl())
->setDatasource($source)
->setLabel($label)
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
->setName('view_user')
->setValue($value)
->setLimit(1);
case 'status':
return id(new AphrontFormToggleButtonsControl())
->setLabel('Status')
->setValue($params['status'])
->setBaseURI($uri, 'status')
->setButtons(
array(
'all' => 'All',
'open' => 'Open',
'closed' => pht('Closed'),
'abandoned' => 'Abandoned',
));
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
case 'order':
return id(new AphrontFormToggleButtonsControl())
->setLabel('Order')
->setValue($params['order'])
->setBaseURI($uri, 'order')
->setButtons(
array(
'modified' => 'Updated',
'created' => 'Created',
));
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
default:
throw new Exception("Unknown control '{$control}'!");
}
}
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
private function applyControlToQuery($control, $query, array $params) {
switch ($control) {
case 'phid':
case 'subscriber':
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
// Already applied by query construction.
break;
case 'status':
if ($params['status'] == 'open') {
$query->withStatus(DifferentialRevisionQuery::STATUS_OPEN);
} else if ($params['status'] == 'closed') {
$query->withStatus(DifferentialRevisionQuery::STATUS_CLOSED);
} else if ($params['status'] == 'abandoned') {
$query->withStatus(DifferentialRevisionQuery::STATUS_ABANDONED);
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
}
break;
case 'order':
if ($params['order'] == 'created') {
$query->setOrder(DifferentialRevisionQuery::ORDER_CREATED);
}
break;
default:
throw new Exception("Unknown control '{$control}'!");
}
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
}
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
private function buildViews($filter, $user_phid, array $revisions) {
assert_instances_of($revisions, 'DifferentialRevision');
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
$user = $this->getRequest()->getUser();
$template = id(new DifferentialRevisionListView())
->setUser($user)
->setFields(DifferentialRevisionListView::getDefaultFields());
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
$views = array();
switch ($filter) {
case 'active':
list($active, $waiting) = DifferentialRevisionQuery::splitResponsible(
$revisions,
$user_phid);
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
$view = id(clone $template)
->setRevisions($active);
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
$views[] = array(
'title' => 'Action Required',
'view' => $view,
);
// Flags are sort of private, so only show the flag panel if you're
// looking at your own requests.
if ($user_phid == $user->getPHID()) {
$flags = id(new PhabricatorFlagQuery())
->withOwnerPHIDs(array($user_phid))
->withTypes(array(PhabricatorPHIDConstants::PHID_TYPE_DREV))
->needHandles(true)
->execute();
if ($flags) {
$view = id(new PhabricatorFlagListView())
->setFlags($flags)
->setUser($user);
$views[] = array(
'title' => 'Flagged Revisions',
'view' => $view,
'special' => true,
);
}
}
$view = id(clone $template)
->setRevisions($waiting);
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
$views[] = array(
'title' => 'Waiting On Others',
'view' => $view,
);
break;
case 'revisions':
case 'reviews':
case 'subscribed':
case 'drafts':
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
case 'all':
$titles = array(
'revisions' => 'Revisions by Author',
'reviews' => 'Revisions by Reviewer',
'subscribed' => 'Revisions by Subscriber',
'all' => 'Revisions',
);
$view = id(clone $template)
->setRevisions($revisions);
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
$views[] = array(
'title' => idx($titles, $filter),
'view' => $view,
);
break;
default:
throw new Exception("Unknown filter '{$filter}'!");
2011-01-27 20:35:04 +01:00
}
Drive Differential landing page with DifferentialRevisionQuery, simplify UI Summary: - Use DifferentialRevisionQuery, not DifferentialRevisionListData, to select revisions. - Make UI simpler (I hope?) and more flexible, similar to Maniphest. It now shows "Active", "Revisions", "Reviews" and "Subscribed" instead of a hodge-podge of miscellaneous stuff. All now really has all revisions, not just open revisions. - Allow views to be filtered and sorted more flexibly. - Allow anonymous users to use the per-user views, just don't default them there. NOTE: This might have performance implications! I need some help evaluating them. @nh / @jungejason / @aran, can one of you run some queries agianst FB's corpus? The "active revisions" view is built much differently now. Before, we issued two queries: - SELECT (open revisions you authored that need revision) UNION ALL (open revisions you are reviewing that need review) - SELECT (open revisions you authored that need review) UNION ALL (open revisions you are reviewing that need revision) These two queries generate the "Action Required" and "Waiting on Others" views, and are available in P247. Now, we issue only one query: - SELECT (open revisions you authored or are reviewing) Then we divide them into the two tables in PHP. That query is available in P246. On the secure.phabricator.com data, this new approach seems to be much better (like, 10x better). But the secure.phabricator.com data isn't very large. Can someone run it against Facebook's data (using a few heavy-hitting PHIDs, like ola or something) to make sure it won't cause a regression? In particular: - Run the queries and make sure the new version doesn't take too long. - Run the queries with EXPLAIN and give me the output maybe? Test Plan: - Looked at different filters. - Changed "View User" PHID. - Changed open/all. - Changed sort order. - Ran EXPLAIN / select against secure.phabricator.com corpus. Reviewers: btrahan, nh, jungejason Reviewed By: btrahan CC: cpiro, aran, btrahan, epriestley, jungejason, nh Maniphest Tasks: T586 Differential Revision: 1186
2011-12-08 00:35:10 +01:00
return $views;
}
2011-01-26 00:19:06 +01:00
}