@recaptime-dev's working patches + fork for Phorge, a community fork of Phabricator. (Upstream dev and stable branches are at upstream/main and upstream/stable respectively.)
hq.recaptime.dev/wiki/Phorge
phorge
phabricator
Add event dispatch for updated search indexes
Summary:
See discussion in D6955. Provide an event for applications and users to update secondary search indexes.
Facebook: I don't recall exactly how all the search stuff is rigged up, but this might provide a more practical / less fragile alternative. I think it publishes into ElasticSearch now, and then intern somehow handles the result merge at display time, implictly relying on Phabricator's storage format? A cleaner approach might be to publish a secondary "intern" index in a standard format.
Test Plan: Ran `bin/search index --type proj --trace`, saw events fire.
Reviewers: btrahan
Reviewed By: btrahan
CC: FacebookPOC, aran
Differential Revision: https://secure.phabricator.com/D6956
+55
-2
+18
-2
src/applications/search/index/PhabricatorSearchDocumentIndexer.php
+18
-2
src/applications/search/index/PhabricatorSearchDocumentIndexer.php
···
44
44
$phid = $document->getPHID();
45
45
$class = get_class($engine);
46
46
47
-
phlog("Unable to index document {$phid} by engine {$class}.");
47
+
phlog("Unable to index document {$phid} with engine {$class}.");
48
48
phlog($ex);
49
49
}
50
50
51
+
$this->dispatchDidUpdateIndexEvent($phid, $document);
51
52
} catch (Exception $ex) {
52
53
$class = get_class($this);
53
-
phlog("Unable to build document {$phid} by indexer {$class}.");
54
+
phlog("Unable to build document {$phid} with indexer {$class}.");
54
55
phlog($ex);
55
56
}
56
57
···
103
104
PhabricatorSearchField::FIELD_COMMENT,
104
105
$comment->getContent());
105
106
}
107
+
}
108
+
109
+
private function dispatchDidUpdateIndexEvent(
110
+
$phid,
111
+
PhabricatorSearchAbstractDocument $document) {
112
+
113
+
$event = new PhabricatorEvent(
114
+
PhabricatorEventType::TYPE_SEARCH_DIDUPDATEINDEX,
115
+
array(
116
+
'phid' => $phid,
117
+
'object' => $this->loadDocumentByPHID($phid),
118
+
'document' => $document,
119
+
));
120
+
$event->setUser($this->getViewer());
121
+
PhutilEventEngine::dispatchEvent($event);
106
122
}
107
123
108
124
}
+35
src/docs/user/userguide/events.diviner
+35
src/docs/user/userguide/events.diviner
···
308
308
This is similar to the previous event (will edit edges) but occurs after the
309
309
edit completes.
310
310
311
+
== Search: Did Update Index ==
312
+
313
+
The constant for this event is
314
+
`PhabricatorEventType::TYPE_SEARCH_DIDUPDATEINDEX`.
315
+
316
+
This event is dispatched from the Search application's indexing engine, after
317
+
it indexes a document. It allows you to publish search-like indexes into other
318
+
systems.
319
+
320
+
Note that this event happens after the update is fully complete: you can not
321
+
prevent or modify the update. Further, the event may fire significantly later
322
+
in real time than the update, as indexing may occur in the background. You
323
+
should use other events if you need guarantees about when the event executes.
324
+
325
+
Finally, this event may fire more than once for a single update. For example,
326
+
if the search indexes are rebuilt, this event will fire on objects which have
327
+
not actually changed.
328
+
329
+
So, good use cases for event listeners are:
330
+
331
+
- Updating secondary search indexes.
332
+
333
+
Bad use cases are:
334
+
335
+
- Editing the object or document.
336
+
- Anything with side effects, like sending email.
337
+
338
+
Data available on this event:
339
+
340
+
- `phid` The PHID of the updated object.
341
+
- `object` The object which was updated (like a @{class:ManiphesTask}).
342
+
- `document` The @{class:PhabricatorSearchAbstractDocument} which was indexed.
343
+
This contains an abstract representation of the object, and may be useful
344
+
in populating secondary indexes because it provides a uniform API.
345
+
311
346
== Test: Did Run Test ==
312
347
313
348
The constant for this event is