Add an assocations-like "Edges" framework
Summary:
We have a lot of cases where we store object relationships, but it's all kind of messy and custom. Some particular problems:
- We go to great lengths to enforce order stability in Differential revisions, but the implementation is complex and inelegant.
- Some relationships are stored on-object, so we can't pull the inverses easily. For example, Maniphest shows child tasks but not parent tasks.
- I want to add more of these and don't want to continue building custom stuff.
- UIs like the "attach stuff to other stuff" UI need custom branches for each object type.
- Stuff like "allow commits to close tasks" is notrivial because of nonstandard metadata storage.
Provide an association-like "edge" framework to fix these problems. This is nearly identical to associations, with a few differences:
- I put edge metadata in a separate table and don't load it by default, to keep edge rows small and allow large metadata if necessary. The on-edge metadata seemed to get abused a lot at Facebook.
- I put a 'seq' column on the edges to ensure they have an explicit, stable ordering within a source and type.
This isn't actually used anywhere yet, but my first target is attaching commits to tasks for T904.
Test Plan: Made a mock page that used Editor and Query. Verified adding and removing edges, overwriting edges, writing and loading edge data, sequence number generation.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran, 20after4
Differential Revision: https://secure.phabricator.com/D2088
2012-04-04 15:30:21 -07:00
|
|
|
<?php
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Load object edges created by @{class:PhabricatorEdgeEditor}.
|
|
|
|
*
|
|
|
|
* name=Querying Edges
|
|
|
|
* $src = $earth_phid;
|
|
|
|
* $type = PhabricatorEdgeConfig::TYPE_BODY_HAS_SATELLITE;
|
|
|
|
*
|
|
|
|
* // Load the earth's satellites.
|
|
|
|
* $satellite_edges = id(new PhabricatorEdgeQuery())
|
|
|
|
* ->withSourcePHIDs(array($src))
|
|
|
|
* ->withEdgeTypes(array($type))
|
|
|
|
* ->execute();
|
|
|
|
*
|
|
|
|
* For more information on edges, see @{article:Using Edges}.
|
|
|
|
*
|
|
|
|
* @task config Configuring the Query
|
|
|
|
* @task exec Executing the Query
|
|
|
|
* @task internal Internal
|
|
|
|
*/
|
|
|
|
final class PhabricatorEdgeQuery extends PhabricatorQuery {
|
|
|
|
|
|
|
|
private $sourcePHIDs;
|
2012-08-08 18:57:38 -07:00
|
|
|
private $destPHIDs;
|
Add an assocations-like "Edges" framework
Summary:
We have a lot of cases where we store object relationships, but it's all kind of messy and custom. Some particular problems:
- We go to great lengths to enforce order stability in Differential revisions, but the implementation is complex and inelegant.
- Some relationships are stored on-object, so we can't pull the inverses easily. For example, Maniphest shows child tasks but not parent tasks.
- I want to add more of these and don't want to continue building custom stuff.
- UIs like the "attach stuff to other stuff" UI need custom branches for each object type.
- Stuff like "allow commits to close tasks" is notrivial because of nonstandard metadata storage.
Provide an association-like "edge" framework to fix these problems. This is nearly identical to associations, with a few differences:
- I put edge metadata in a separate table and don't load it by default, to keep edge rows small and allow large metadata if necessary. The on-edge metadata seemed to get abused a lot at Facebook.
- I put a 'seq' column on the edges to ensure they have an explicit, stable ordering within a source and type.
This isn't actually used anywhere yet, but my first target is attaching commits to tasks for T904.
Test Plan: Made a mock page that used Editor and Query. Verified adding and removing edges, overwriting edges, writing and loading edge data, sequence number generation.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran, 20after4
Differential Revision: https://secure.phabricator.com/D2088
2012-04-04 15:30:21 -07:00
|
|
|
private $edgeTypes;
|
2012-07-18 20:41:26 -07:00
|
|
|
private $resultSet;
|
Add an assocations-like "Edges" framework
Summary:
We have a lot of cases where we store object relationships, but it's all kind of messy and custom. Some particular problems:
- We go to great lengths to enforce order stability in Differential revisions, but the implementation is complex and inelegant.
- Some relationships are stored on-object, so we can't pull the inverses easily. For example, Maniphest shows child tasks but not parent tasks.
- I want to add more of these and don't want to continue building custom stuff.
- UIs like the "attach stuff to other stuff" UI need custom branches for each object type.
- Stuff like "allow commits to close tasks" is notrivial because of nonstandard metadata storage.
Provide an association-like "edge" framework to fix these problems. This is nearly identical to associations, with a few differences:
- I put edge metadata in a separate table and don't load it by default, to keep edge rows small and allow large metadata if necessary. The on-edge metadata seemed to get abused a lot at Facebook.
- I put a 'seq' column on the edges to ensure they have an explicit, stable ordering within a source and type.
This isn't actually used anywhere yet, but my first target is attaching commits to tasks for T904.
Test Plan: Made a mock page that used Editor and Query. Verified adding and removing edges, overwriting edges, writing and loading edge data, sequence number generation.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran, 20after4
Differential Revision: https://secure.phabricator.com/D2088
2012-04-04 15:30:21 -07:00
|
|
|
|
2013-10-04 19:57:15 -07:00
|
|
|
const ORDER_OLDEST_FIRST = 'order:oldest';
|
|
|
|
const ORDER_NEWEST_FIRST = 'order:newest';
|
|
|
|
private $order = self::ORDER_NEWEST_FIRST;
|
|
|
|
|
Add an assocations-like "Edges" framework
Summary:
We have a lot of cases where we store object relationships, but it's all kind of messy and custom. Some particular problems:
- We go to great lengths to enforce order stability in Differential revisions, but the implementation is complex and inelegant.
- Some relationships are stored on-object, so we can't pull the inverses easily. For example, Maniphest shows child tasks but not parent tasks.
- I want to add more of these and don't want to continue building custom stuff.
- UIs like the "attach stuff to other stuff" UI need custom branches for each object type.
- Stuff like "allow commits to close tasks" is notrivial because of nonstandard metadata storage.
Provide an association-like "edge" framework to fix these problems. This is nearly identical to associations, with a few differences:
- I put edge metadata in a separate table and don't load it by default, to keep edge rows small and allow large metadata if necessary. The on-edge metadata seemed to get abused a lot at Facebook.
- I put a 'seq' column on the edges to ensure they have an explicit, stable ordering within a source and type.
This isn't actually used anywhere yet, but my first target is attaching commits to tasks for T904.
Test Plan: Made a mock page that used Editor and Query. Verified adding and removing edges, overwriting edges, writing and loading edge data, sequence number generation.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran, 20after4
Differential Revision: https://secure.phabricator.com/D2088
2012-04-04 15:30:21 -07:00
|
|
|
private $needEdgeData;
|
|
|
|
|
|
|
|
|
|
|
|
/* -( Configuring the Query )---------------------------------------------- */
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Find edges originating at one or more source PHIDs. You MUST provide this
|
|
|
|
* to execute an edge query.
|
|
|
|
*
|
|
|
|
* @param list List of source PHIDs.
|
|
|
|
* @return this
|
|
|
|
*
|
|
|
|
* @task config
|
|
|
|
*/
|
|
|
|
public function withSourcePHIDs(array $source_phids) {
|
|
|
|
$this->sourcePHIDs = $source_phids;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2012-08-08 18:57:38 -07:00
|
|
|
/**
|
|
|
|
* Find edges terminating at one or more destination PHIDs.
|
|
|
|
*
|
|
|
|
* @param list List of destination PHIDs.
|
|
|
|
* @return this
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
public function withDestinationPHIDs(array $dest_phids) {
|
|
|
|
$this->destPHIDs = $dest_phids;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
Add an assocations-like "Edges" framework
Summary:
We have a lot of cases where we store object relationships, but it's all kind of messy and custom. Some particular problems:
- We go to great lengths to enforce order stability in Differential revisions, but the implementation is complex and inelegant.
- Some relationships are stored on-object, so we can't pull the inverses easily. For example, Maniphest shows child tasks but not parent tasks.
- I want to add more of these and don't want to continue building custom stuff.
- UIs like the "attach stuff to other stuff" UI need custom branches for each object type.
- Stuff like "allow commits to close tasks" is notrivial because of nonstandard metadata storage.
Provide an association-like "edge" framework to fix these problems. This is nearly identical to associations, with a few differences:
- I put edge metadata in a separate table and don't load it by default, to keep edge rows small and allow large metadata if necessary. The on-edge metadata seemed to get abused a lot at Facebook.
- I put a 'seq' column on the edges to ensure they have an explicit, stable ordering within a source and type.
This isn't actually used anywhere yet, but my first target is attaching commits to tasks for T904.
Test Plan: Made a mock page that used Editor and Query. Verified adding and removing edges, overwriting edges, writing and loading edge data, sequence number generation.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran, 20after4
Differential Revision: https://secure.phabricator.com/D2088
2012-04-04 15:30:21 -07:00
|
|
|
/**
|
|
|
|
* Find edges of specific types.
|
|
|
|
*
|
|
|
|
* @param list List of PhabricatorEdgeConfig type constants.
|
|
|
|
* @return this
|
|
|
|
*
|
|
|
|
* @task config
|
|
|
|
*/
|
|
|
|
public function withEdgeTypes(array $types) {
|
|
|
|
$this->edgeTypes = $types;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2013-10-04 19:57:15 -07:00
|
|
|
/**
|
|
|
|
* Configure the order edge results are returned in.
|
|
|
|
*
|
|
|
|
* @param const Order constant.
|
|
|
|
* @return this
|
|
|
|
*
|
|
|
|
* @task config
|
|
|
|
*/
|
|
|
|
public function setOrder($order) {
|
|
|
|
$this->order = $order;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
Add an assocations-like "Edges" framework
Summary:
We have a lot of cases where we store object relationships, but it's all kind of messy and custom. Some particular problems:
- We go to great lengths to enforce order stability in Differential revisions, but the implementation is complex and inelegant.
- Some relationships are stored on-object, so we can't pull the inverses easily. For example, Maniphest shows child tasks but not parent tasks.
- I want to add more of these and don't want to continue building custom stuff.
- UIs like the "attach stuff to other stuff" UI need custom branches for each object type.
- Stuff like "allow commits to close tasks" is notrivial because of nonstandard metadata storage.
Provide an association-like "edge" framework to fix these problems. This is nearly identical to associations, with a few differences:
- I put edge metadata in a separate table and don't load it by default, to keep edge rows small and allow large metadata if necessary. The on-edge metadata seemed to get abused a lot at Facebook.
- I put a 'seq' column on the edges to ensure they have an explicit, stable ordering within a source and type.
This isn't actually used anywhere yet, but my first target is attaching commits to tasks for T904.
Test Plan: Made a mock page that used Editor and Query. Verified adding and removing edges, overwriting edges, writing and loading edge data, sequence number generation.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran, 20after4
Differential Revision: https://secure.phabricator.com/D2088
2012-04-04 15:30:21 -07:00
|
|
|
/**
|
|
|
|
* When loading edges, also load edge data.
|
|
|
|
*
|
|
|
|
* @param bool True to load edge data.
|
|
|
|
* @return this
|
|
|
|
*
|
|
|
|
* @task config
|
|
|
|
*/
|
|
|
|
public function needEdgeData($need) {
|
|
|
|
$this->needEdgeData = $need;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* -( Executing the Query )------------------------------------------------ */
|
|
|
|
|
|
|
|
|
2012-04-04 17:34:25 -07:00
|
|
|
/**
|
|
|
|
* Convenience method for loading destination PHIDs with one source and one
|
|
|
|
* edge type. Equivalent to building a full query, but simplifies a common
|
|
|
|
* use case.
|
|
|
|
*
|
|
|
|
* @param phid Source PHID.
|
|
|
|
* @param const Edge type.
|
|
|
|
* @return list<phid> List of destination PHIDs.
|
|
|
|
*/
|
|
|
|
public static function loadDestinationPHIDs($src_phid, $edge_type) {
|
|
|
|
$edges = id(new PhabricatorEdgeQuery())
|
|
|
|
->withSourcePHIDs(array($src_phid))
|
|
|
|
->withEdgeTypes(array($edge_type))
|
|
|
|
->execute();
|
|
|
|
return array_keys($edges[$src_phid][$edge_type]);
|
|
|
|
}
|
|
|
|
|
2012-08-08 18:57:38 -07:00
|
|
|
/**
|
|
|
|
* Convenience method for loading a single edge's metadata for
|
|
|
|
* a given source, destination, and edge type. Returns null
|
|
|
|
* if the edge does not exist or does not have metadata. Builds
|
|
|
|
* and immediately executes a full query.
|
|
|
|
*
|
|
|
|
* @param phid Source PHID.
|
|
|
|
* @param const Edge type.
|
|
|
|
* @param phid Destination PHID.
|
|
|
|
* @return wild Edge annotation (or null).
|
|
|
|
*/
|
|
|
|
public static function loadSingleEdgeData($src_phid, $edge_type, $dest_phid) {
|
|
|
|
$edges = id(new PhabricatorEdgeQuery())
|
|
|
|
->withSourcePHIDs(array($src_phid))
|
|
|
|
->withEdgeTypes(array($edge_type))
|
|
|
|
->withDestinationPHIDs(array($dest_phid))
|
|
|
|
->needEdgeData(true)
|
|
|
|
->execute();
|
|
|
|
|
|
|
|
if (isset($edges[$src_phid][$edge_type][$dest_phid]['data'])) {
|
|
|
|
return $edges[$src_phid][$edge_type][$dest_phid]['data'];
|
|
|
|
}
|
|
|
|
return null;
|
|
|
|
}
|
|
|
|
|
2012-04-04 17:34:25 -07:00
|
|
|
|
Add an assocations-like "Edges" framework
Summary:
We have a lot of cases where we store object relationships, but it's all kind of messy and custom. Some particular problems:
- We go to great lengths to enforce order stability in Differential revisions, but the implementation is complex and inelegant.
- Some relationships are stored on-object, so we can't pull the inverses easily. For example, Maniphest shows child tasks but not parent tasks.
- I want to add more of these and don't want to continue building custom stuff.
- UIs like the "attach stuff to other stuff" UI need custom branches for each object type.
- Stuff like "allow commits to close tasks" is notrivial because of nonstandard metadata storage.
Provide an association-like "edge" framework to fix these problems. This is nearly identical to associations, with a few differences:
- I put edge metadata in a separate table and don't load it by default, to keep edge rows small and allow large metadata if necessary. The on-edge metadata seemed to get abused a lot at Facebook.
- I put a 'seq' column on the edges to ensure they have an explicit, stable ordering within a source and type.
This isn't actually used anywhere yet, but my first target is attaching commits to tasks for T904.
Test Plan: Made a mock page that used Editor and Query. Verified adding and removing edges, overwriting edges, writing and loading edge data, sequence number generation.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran, 20after4
Differential Revision: https://secure.phabricator.com/D2088
2012-04-04 15:30:21 -07:00
|
|
|
/**
|
|
|
|
* Load specified edges.
|
|
|
|
*
|
|
|
|
* @task exec
|
|
|
|
*/
|
|
|
|
public function execute() {
|
|
|
|
if (!$this->sourcePHIDs) {
|
|
|
|
throw new Exception(
|
2014-06-09 11:36:49 -07:00
|
|
|
'You must use withSourcePHIDs() to query edges.');
|
Add an assocations-like "Edges" framework
Summary:
We have a lot of cases where we store object relationships, but it's all kind of messy and custom. Some particular problems:
- We go to great lengths to enforce order stability in Differential revisions, but the implementation is complex and inelegant.
- Some relationships are stored on-object, so we can't pull the inverses easily. For example, Maniphest shows child tasks but not parent tasks.
- I want to add more of these and don't want to continue building custom stuff.
- UIs like the "attach stuff to other stuff" UI need custom branches for each object type.
- Stuff like "allow commits to close tasks" is notrivial because of nonstandard metadata storage.
Provide an association-like "edge" framework to fix these problems. This is nearly identical to associations, with a few differences:
- I put edge metadata in a separate table and don't load it by default, to keep edge rows small and allow large metadata if necessary. The on-edge metadata seemed to get abused a lot at Facebook.
- I put a 'seq' column on the edges to ensure they have an explicit, stable ordering within a source and type.
This isn't actually used anywhere yet, but my first target is attaching commits to tasks for T904.
Test Plan: Made a mock page that used Editor and Query. Verified adding and removing edges, overwriting edges, writing and loading edge data, sequence number generation.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran, 20after4
Differential Revision: https://secure.phabricator.com/D2088
2012-04-04 15:30:21 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
$sources = phid_group_by_type($this->sourcePHIDs);
|
|
|
|
|
|
|
|
$result = array();
|
|
|
|
|
|
|
|
// When a query specifies types, make sure we return data for all queried
|
2013-09-13 11:40:52 -07:00
|
|
|
// types.
|
Add an assocations-like "Edges" framework
Summary:
We have a lot of cases where we store object relationships, but it's all kind of messy and custom. Some particular problems:
- We go to great lengths to enforce order stability in Differential revisions, but the implementation is complex and inelegant.
- Some relationships are stored on-object, so we can't pull the inverses easily. For example, Maniphest shows child tasks but not parent tasks.
- I want to add more of these and don't want to continue building custom stuff.
- UIs like the "attach stuff to other stuff" UI need custom branches for each object type.
- Stuff like "allow commits to close tasks" is notrivial because of nonstandard metadata storage.
Provide an association-like "edge" framework to fix these problems. This is nearly identical to associations, with a few differences:
- I put edge metadata in a separate table and don't load it by default, to keep edge rows small and allow large metadata if necessary. The on-edge metadata seemed to get abused a lot at Facebook.
- I put a 'seq' column on the edges to ensure they have an explicit, stable ordering within a source and type.
This isn't actually used anywhere yet, but my first target is attaching commits to tasks for T904.
Test Plan: Made a mock page that used Editor and Query. Verified adding and removing edges, overwriting edges, writing and loading edge data, sequence number generation.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran, 20after4
Differential Revision: https://secure.phabricator.com/D2088
2012-04-04 15:30:21 -07:00
|
|
|
if ($this->edgeTypes) {
|
|
|
|
foreach ($this->sourcePHIDs as $phid) {
|
|
|
|
foreach ($this->edgeTypes as $type) {
|
|
|
|
$result[$phid][$type] = array();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
foreach ($sources as $type => $phids) {
|
|
|
|
$conn_r = PhabricatorEdgeConfig::establishConnection($type, 'r');
|
|
|
|
|
|
|
|
$where = $this->buildWhereClause($conn_r);
|
|
|
|
$order = $this->buildOrderClause($conn_r);
|
|
|
|
|
|
|
|
$edges = queryfx_all(
|
|
|
|
$conn_r,
|
|
|
|
'SELECT edge.* FROM %T edge %Q %Q',
|
|
|
|
PhabricatorEdgeConfig::TABLE_NAME_EDGE,
|
|
|
|
$where,
|
|
|
|
$order);
|
|
|
|
|
|
|
|
if ($this->needEdgeData) {
|
|
|
|
$data_ids = array_filter(ipull($edges, 'dataID'));
|
|
|
|
$data_map = array();
|
|
|
|
if ($data_ids) {
|
|
|
|
$data_rows = queryfx_all(
|
|
|
|
$conn_r,
|
|
|
|
'SELECT edgedata.* FROM %T edgedata WHERE id IN (%Ld)',
|
|
|
|
PhabricatorEdgeConfig::TABLE_NAME_EDGEDATA,
|
|
|
|
$data_ids);
|
|
|
|
foreach ($data_rows as $row) {
|
|
|
|
$data_map[$row['id']] = idx(
|
|
|
|
json_decode($row['data'], true),
|
|
|
|
'data');
|
|
|
|
}
|
|
|
|
}
|
|
|
|
foreach ($edges as $key => $edge) {
|
2013-06-25 16:30:06 -07:00
|
|
|
$edges[$key]['data'] = idx($data_map, $edge['dataID'], array());
|
Add an assocations-like "Edges" framework
Summary:
We have a lot of cases where we store object relationships, but it's all kind of messy and custom. Some particular problems:
- We go to great lengths to enforce order stability in Differential revisions, but the implementation is complex and inelegant.
- Some relationships are stored on-object, so we can't pull the inverses easily. For example, Maniphest shows child tasks but not parent tasks.
- I want to add more of these and don't want to continue building custom stuff.
- UIs like the "attach stuff to other stuff" UI need custom branches for each object type.
- Stuff like "allow commits to close tasks" is notrivial because of nonstandard metadata storage.
Provide an association-like "edge" framework to fix these problems. This is nearly identical to associations, with a few differences:
- I put edge metadata in a separate table and don't load it by default, to keep edge rows small and allow large metadata if necessary. The on-edge metadata seemed to get abused a lot at Facebook.
- I put a 'seq' column on the edges to ensure they have an explicit, stable ordering within a source and type.
This isn't actually used anywhere yet, but my first target is attaching commits to tasks for T904.
Test Plan: Made a mock page that used Editor and Query. Verified adding and removing edges, overwriting edges, writing and loading edge data, sequence number generation.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran, 20after4
Differential Revision: https://secure.phabricator.com/D2088
2012-04-04 15:30:21 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
foreach ($edges as $edge) {
|
|
|
|
$result[$edge['src']][$edge['type']][$edge['dst']] = $edge;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-07-18 20:41:26 -07:00
|
|
|
$this->resultSet = $result;
|
Add an assocations-like "Edges" framework
Summary:
We have a lot of cases where we store object relationships, but it's all kind of messy and custom. Some particular problems:
- We go to great lengths to enforce order stability in Differential revisions, but the implementation is complex and inelegant.
- Some relationships are stored on-object, so we can't pull the inverses easily. For example, Maniphest shows child tasks but not parent tasks.
- I want to add more of these and don't want to continue building custom stuff.
- UIs like the "attach stuff to other stuff" UI need custom branches for each object type.
- Stuff like "allow commits to close tasks" is notrivial because of nonstandard metadata storage.
Provide an association-like "edge" framework to fix these problems. This is nearly identical to associations, with a few differences:
- I put edge metadata in a separate table and don't load it by default, to keep edge rows small and allow large metadata if necessary. The on-edge metadata seemed to get abused a lot at Facebook.
- I put a 'seq' column on the edges to ensure they have an explicit, stable ordering within a source and type.
This isn't actually used anywhere yet, but my first target is attaching commits to tasks for T904.
Test Plan: Made a mock page that used Editor and Query. Verified adding and removing edges, overwriting edges, writing and loading edge data, sequence number generation.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran, 20after4
Differential Revision: https://secure.phabricator.com/D2088
2012-04-04 15:30:21 -07:00
|
|
|
return $result;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2012-07-18 20:41:26 -07:00
|
|
|
/**
|
|
|
|
* Convenience function for selecting edge destination PHIDs after calling
|
|
|
|
* execute().
|
|
|
|
*
|
|
|
|
* Returns a flat list of PHIDs matching the provided source PHID and type
|
|
|
|
* filters. By default, the filters are empty so all PHIDs will be returned.
|
|
|
|
* For example, if you're doing a batch query from several sources, you might
|
|
|
|
* write code like this:
|
|
|
|
*
|
|
|
|
* $query = new PhabricatorEdgeQuery();
|
2013-02-28 17:15:09 -08:00
|
|
|
* $query->setViewer($viewer);
|
2012-07-18 20:41:26 -07:00
|
|
|
* $query->withSourcePHIDs(mpull($objects, 'getPHID'));
|
|
|
|
* $query->withEdgeTypes(array($some_type));
|
|
|
|
* $query->execute();
|
|
|
|
*
|
|
|
|
* // Gets all of the destinations.
|
|
|
|
* $all_phids = $query->getDestinationPHIDs();
|
2013-09-11 12:27:28 -07:00
|
|
|
* $handles = id(new PhabricatorHandleQuery())
|
2013-02-28 17:15:09 -08:00
|
|
|
* ->setViewer($viewer)
|
2013-09-11 12:27:28 -07:00
|
|
|
* ->withPHIDs($all_phids)
|
|
|
|
* ->execute();
|
2012-07-18 20:41:26 -07:00
|
|
|
*
|
|
|
|
* foreach ($objects as $object) {
|
|
|
|
* // Get all of the destinations for the given object.
|
|
|
|
* $dst_phids = $query->getDestinationPHIDs(array($object->getPHID()));
|
|
|
|
* $object->attachHandles(array_select_keys($handles, $dst_phids));
|
|
|
|
* }
|
|
|
|
*
|
|
|
|
* @param list? List of PHIDs to select, or empty to select all.
|
|
|
|
* @param list? List of edge types to select, or empty to select all.
|
|
|
|
* @return list<phid> List of matching destination PHIDs.
|
|
|
|
*/
|
|
|
|
public function getDestinationPHIDs(
|
|
|
|
array $src_phids = array(),
|
|
|
|
array $types = array()) {
|
|
|
|
if ($this->resultSet === null) {
|
|
|
|
throw new Exception(
|
2014-06-09 11:36:49 -07:00
|
|
|
'You must execute() a query before you you can getDestinationPHIDs().');
|
2012-07-18 20:41:26 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
$result_phids = array();
|
2014-12-02 05:51:46 -08:00
|
|
|
|
|
|
|
$set = $this->resultSet;
|
|
|
|
if ($src_phids) {
|
|
|
|
$set = array_select_keys($set, $src_phids);
|
|
|
|
}
|
|
|
|
|
|
|
|
foreach ($set as $src => $edges_by_type) {
|
|
|
|
if ($types) {
|
|
|
|
$edges_by_type = array_select_keys($edges_by_type, $types);
|
2012-07-18 20:41:26 -07:00
|
|
|
}
|
2014-12-02 05:51:46 -08:00
|
|
|
|
|
|
|
foreach ($edges_by_type as $edges) {
|
|
|
|
foreach ($edges as $edge_phid => $edge) {
|
|
|
|
$result_phids[$edge_phid] = true;
|
2012-07-18 20:41:26 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return array_keys($result_phids);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
Add an assocations-like "Edges" framework
Summary:
We have a lot of cases where we store object relationships, but it's all kind of messy and custom. Some particular problems:
- We go to great lengths to enforce order stability in Differential revisions, but the implementation is complex and inelegant.
- Some relationships are stored on-object, so we can't pull the inverses easily. For example, Maniphest shows child tasks but not parent tasks.
- I want to add more of these and don't want to continue building custom stuff.
- UIs like the "attach stuff to other stuff" UI need custom branches for each object type.
- Stuff like "allow commits to close tasks" is notrivial because of nonstandard metadata storage.
Provide an association-like "edge" framework to fix these problems. This is nearly identical to associations, with a few differences:
- I put edge metadata in a separate table and don't load it by default, to keep edge rows small and allow large metadata if necessary. The on-edge metadata seemed to get abused a lot at Facebook.
- I put a 'seq' column on the edges to ensure they have an explicit, stable ordering within a source and type.
This isn't actually used anywhere yet, but my first target is attaching commits to tasks for T904.
Test Plan: Made a mock page that used Editor and Query. Verified adding and removing edges, overwriting edges, writing and loading edge data, sequence number generation.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran, 20after4
Differential Revision: https://secure.phabricator.com/D2088
2012-04-04 15:30:21 -07:00
|
|
|
/* -( Internals )---------------------------------------------------------- */
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @task internal
|
|
|
|
*/
|
|
|
|
private function buildWhereClause($conn_r) {
|
|
|
|
$where = array();
|
|
|
|
|
|
|
|
if ($this->sourcePHIDs) {
|
|
|
|
$where[] = qsprintf(
|
|
|
|
$conn_r,
|
|
|
|
'edge.src IN (%Ls)',
|
|
|
|
$this->sourcePHIDs);
|
|
|
|
}
|
|
|
|
|
|
|
|
if ($this->edgeTypes) {
|
|
|
|
$where[] = qsprintf(
|
|
|
|
$conn_r,
|
|
|
|
'edge.type IN (%Ls)',
|
|
|
|
$this->edgeTypes);
|
|
|
|
}
|
|
|
|
|
2012-08-08 18:57:38 -07:00
|
|
|
if ($this->destPHIDs) {
|
|
|
|
// potentially complain if $this->edgeType was not set
|
|
|
|
$where[] = qsprintf(
|
|
|
|
$conn_r,
|
|
|
|
'edge.dst IN (%Ls)',
|
|
|
|
$this->destPHIDs);
|
|
|
|
}
|
|
|
|
|
Add an assocations-like "Edges" framework
Summary:
We have a lot of cases where we store object relationships, but it's all kind of messy and custom. Some particular problems:
- We go to great lengths to enforce order stability in Differential revisions, but the implementation is complex and inelegant.
- Some relationships are stored on-object, so we can't pull the inverses easily. For example, Maniphest shows child tasks but not parent tasks.
- I want to add more of these and don't want to continue building custom stuff.
- UIs like the "attach stuff to other stuff" UI need custom branches for each object type.
- Stuff like "allow commits to close tasks" is notrivial because of nonstandard metadata storage.
Provide an association-like "edge" framework to fix these problems. This is nearly identical to associations, with a few differences:
- I put edge metadata in a separate table and don't load it by default, to keep edge rows small and allow large metadata if necessary. The on-edge metadata seemed to get abused a lot at Facebook.
- I put a 'seq' column on the edges to ensure they have an explicit, stable ordering within a source and type.
This isn't actually used anywhere yet, but my first target is attaching commits to tasks for T904.
Test Plan: Made a mock page that used Editor and Query. Verified adding and removing edges, overwriting edges, writing and loading edge data, sequence number generation.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran, 20after4
Differential Revision: https://secure.phabricator.com/D2088
2012-04-04 15:30:21 -07:00
|
|
|
return $this->formatWhereClause($where);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @task internal
|
|
|
|
*/
|
|
|
|
private function buildOrderClause($conn_r) {
|
2013-10-04 19:57:15 -07:00
|
|
|
if ($this->order == self::ORDER_NEWEST_FIRST) {
|
|
|
|
return 'ORDER BY edge.dateCreated DESC, edge.seq DESC';
|
|
|
|
} else {
|
|
|
|
return 'ORDER BY edge.dateCreated ASC, edge.seq ASC';
|
|
|
|
}
|
Add an assocations-like "Edges" framework
Summary:
We have a lot of cases where we store object relationships, but it's all kind of messy and custom. Some particular problems:
- We go to great lengths to enforce order stability in Differential revisions, but the implementation is complex and inelegant.
- Some relationships are stored on-object, so we can't pull the inverses easily. For example, Maniphest shows child tasks but not parent tasks.
- I want to add more of these and don't want to continue building custom stuff.
- UIs like the "attach stuff to other stuff" UI need custom branches for each object type.
- Stuff like "allow commits to close tasks" is notrivial because of nonstandard metadata storage.
Provide an association-like "edge" framework to fix these problems. This is nearly identical to associations, with a few differences:
- I put edge metadata in a separate table and don't load it by default, to keep edge rows small and allow large metadata if necessary. The on-edge metadata seemed to get abused a lot at Facebook.
- I put a 'seq' column on the edges to ensure they have an explicit, stable ordering within a source and type.
This isn't actually used anywhere yet, but my first target is attaching commits to tasks for T904.
Test Plan: Made a mock page that used Editor and Query. Verified adding and removing edges, overwriting edges, writing and loading edge data, sequence number generation.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran, 20after4
Differential Revision: https://secure.phabricator.com/D2088
2012-04-04 15:30:21 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
}
|