LiskDAO->loadOneRelative() was an early idea for dealing with the N + 1 query problem by letting you write traditional N + 1 code:
$stuff = load_stuff();
foreach ($stuff as $thing) {
$thing->loadOneRelatedThing();
}...and optimizing it down to two queries by tracking that all the $stuff objects were related and loadOneRelatedThing() can actually load the related thing for all the objects in the set in the first iteration and then hit the cache for every subsequent iteration.
This didn't end up matching up to Phabricator use cases terribly well, particularly with the later addition of per-object policies. This mechanism is rarely used and should be removed.
epriestley@orbital ~/dev/phabricator $ git grep -i loadOneRelative
resources/sql/patches/20130219.commitsummarymig.php: $data = $commit->loadOneRelative(
resources/sql/patches/20130409.commitdrev.php: $data = $commit->loadOneRelative($data_table, 'commitID');
src/applications/people/storage/PhabricatorUser.php: return $this->loadOneRelative(
src/applications/releeph/conduit/ReleephGetBranchesConduitAPIMethod.php: $cut_point_commit = $branch->loadOneRelative(
src/applications/releeph/storage/ReleephRequest.php: return $this->loadOneRelative(
src/applications/releeph/storage/ReleephRequest.php: return $commit->loadOneRelative(
src/infrastructure/storage/lisk/LiskDAO.php: * of all diffs (using shortcut @{method:loadOneRelative}):
src/infrastructure/storage/lisk/LiskDAO.php: * $author = $diff->loadOneRelative(
src/infrastructure/storage/lisk/LiskDAO.php: * $status = $author->loadOneRelative(
src/infrastructure/storage/lisk/LiskDAO.php: final public function loadOneRelative(