mirror of
https://we.phorge.it/source/phorge.git
synced 2024-11-28 09:42:41 +01:00
2160c45619
Summary: Ref T9964. We have various kinds of secondary data on objects (like subscribers, projects, paste content, Owners paths, file attachments, etc) which is somewhat slow, or somewhat large, or both. Some approaches to handling this in the API include: - Always return all of it (very easy, but slow). - Require users to make separate API calls to get each piece of data (very simple, but inefficient and really cumbersome to use). - Implement a hierarchical query language like GraphQL (powerful, but very complex). - Kind of mix-and-match a half-power query language and some extra calls? (fairly simple, not too terrible?) We currently mix-and-match internally, with `->needStuff(true)`. This is not a general-purpose, full-power graph query language like GraphQL, and it occasionally does limit us. For example, there is no way to do this sort of thing: $conpherence_thread_query = id(new ConpherenceThreadQuery()) ->setViewer($viewer) // ... ->setNeedMessages(true) ->setWhenYouLoadTheMessagesTheyNeedProfilePictures(true); However, we almost never actually need to do this and when we do want to do it we usually don't //really// want to do it, so I don't think this is a major limit to the practical power of the system for the kinds of things we really want to do with it. Put another way, we have a lot of 1-level hierarchical queries (get pictures or repositories or projects or files or content for these objects) but few-to-no 2+ level queries (get files for these objects, then get all the projects for those files). So even though 1-level hierarchies are not a beautiful, general-purpose, fully-abstract system, they've worked well so far in practice and I'm comfortable moving forward with them in the API. If we do need N-level queries in the future, there is no technical reason we can't put GraphQL (or something similar) on top of this eventually, and this would represent a solid step toward that. However, I suspect we'll never need them. Upshot: I'm pretty happy with "->needX()" for all practical purposes, so this is just adding a way to say "->needX()" to the API. Specifically, you say: ``` { "attachments": { "subscribers": true, } } ``` ...and get back subscriber data. In the future (or for certain attachments), `true` might become a dictionary of extra parameters, if necessary, and could do so without breaking the API. Test Plan: - Ran queries to get attachments. {F1025449} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14772
50 lines
1.1 KiB
PHP
50 lines
1.1 KiB
PHP
<?php
|
|
|
|
abstract class PhabricatorSearchEngineAttachment extends Phobject {
|
|
|
|
private $attachmentKey;
|
|
private $viewer;
|
|
private $searchEngine;
|
|
|
|
final public function setViewer($viewer) {
|
|
$this->viewer = $viewer;
|
|
return $this;
|
|
}
|
|
|
|
final public function getViewer() {
|
|
return $this->viewer;
|
|
}
|
|
|
|
final public function setSearchEngine(
|
|
PhabricatorApplicationSearchEngine $engine) {
|
|
$this->searchEngine = $engine;
|
|
return $this;
|
|
}
|
|
|
|
final public function getSearchEngine() {
|
|
return $this->searchEngine;
|
|
}
|
|
|
|
public function setAttachmentKey($attachment_key) {
|
|
$this->attachmentKey = $attachment_key;
|
|
return $this;
|
|
}
|
|
|
|
public function getAttachmentKey() {
|
|
return $this->attachmentKey;
|
|
}
|
|
|
|
abstract public function getAttachmentName();
|
|
abstract public function getAttachmentDescription();
|
|
|
|
public function willLoadAttachmentData($query, $spec) {
|
|
return;
|
|
}
|
|
|
|
public function loadAttachmentData(array $objects, $spec) {
|
|
return null;
|
|
}
|
|
|
|
abstract public function getAttachmentForObject($object, $data, $spec);
|
|
|
|
}
|