Page MenuHomePhabricator

Add a generic "edge.search" method
ClosedPublic

Authored by epriestley on Mar 4 2017, 5:53 PM.
Tags
None
Referenced Files
F18779811: D17462.diff
Sat, Oct 11, 3:29 PM
F18743257: D17462.id.diff
Thu, Oct 2, 10:59 PM
F18738099: D17462.diff
Wed, Oct 1, 2:05 PM
F18703247: D17462.id41992.diff
Sun, Sep 28, 3:22 AM
F18686211: D17462.id41999.diff
Fri, Sep 26, 12:14 PM
F18600218: D17462.id41999.diff
Sep 13 2025, 9:15 AM
F18591470: D17462.diff
Sep 12 2025, 9:19 AM
F18585684: D17462.id41999.diff
Sep 11 2025, 4:03 PM
Subscribers
None

Details

Summary

Ref T12337. Ref T5873. This provides a generic "edge.search" method which feels like other "verison 3" *.search methods.

The major issues here are:

  1. Edges use constants internally, which aren't great for an API.
  2. A lot of edges are internal and probably not useful to query.
  3. Edges don't have a real "id", so paginating them properly is challenging.

I've solved these things like this:

  • Edges must opt-in to being available via Conduit by providing a human-readable key (like "mention" instead of "52"). This solvs (1) and (2).
  • I faked a mostly-reasonable behavior for paginating.
Test Plan

Ran various valid and invalid searches. Paginated a large search. Reviewed UI.

Screen Shot 2017-03-04 at 9.47.21 AM.png (1×1 px, 164 KB)

Diff Detail

Repository
rP Phabricator
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

which feels like

Well, somewhat like. I could put the sourcePHIDs and such in a constraints parameter, but that felt more confusing than helpful even though it would make them feel a little more similar.

This revision is now accepted and ready to land.Mar 4 2017, 8:33 PM
This revision was automatically updated to reflect the committed changes.