Page MenuHomePhabricator

Give `arc` query workflows (arc tasks, arc list) access to ApplicationSearch
Open, Needs TriagePublic

Description

At the suggestion of another user, I'm adding a Maniphest task for my feature suggestion, which I've (prematurely) diffed and patched up as D12165.

Related Objects

StatusAssignedTask
Resolvedepriestley
Resolvedepriestley
Resolvedepriestley
OpenNone
Openepriestley
Resolvedepriestley
ResolvedNone
Resolvedepriestley
Resolvedepriestley
Resolvedepriestley
DuplicateNone
OpenNone

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

This is nice feature and I'm using D12165 as patch and it's cool. It seems like good connection between arc tasks and arc todo now that in both of those You can use --project

epriestley renamed this task from Add --project filter to "arc tasks" workflow to Give `arc` query workflows (arc tasks, arc list) access to ApplicationSearch.May 11 2015, 1:24 PM
epriestley added subscribers: epriestley, magnetik, Erethon.

I don't want to add flags one by one for this. This approach is time-consuming and not very powerful. To provide one specific example, supporting custom fields via hard-coded flags in the arc client is not practical without some level of generalization.

Instead, I want to drive these CLI query workflows through ApplicationSearch. Examples would be:

# Run the "Assigned" builtin query.
$ arc list --query assigned 

# Run the "All Tasks" builtin query.
$ arc list --query all

# Run an ad-hoc parameterized query (open tasks in your projects not tagged "bug").
$ arc list --query 'projects=viewerprojects(),not(bug)&statuses=open()'

This would give us:

  • a single, consistent, full-power query language across the web UI, conduit, the CLI, dashboard panels and HTTP parameters;
  • automatic support for new fields, new orders, custom fields, new constraints, new typeahead functions, etc., across all UIs;
  • integration between the web UI and Conduit/CLI (so you write queries with the web interface, then run them from other contexts).

To do this, we need to take these steps:

Let ApplicationSearch know about search fields. Currently, ApplicationSearch doesn't read query parameters in a structured, introspectable way. That is, given a SearchEngine $engine object, there's no method you can call to ask it which parameters it accepts: you have to pass in a bundle of parameters and hope for the best. The parameter spec is informally encoded in the construction of the HTML form which submits queries. ApplicationSearch needs to be restructured so that each SearchEngine emits some sort of parameter spec and buildSavedQueryFromRequest() just reads this spec.

Drive Conduit through ApplicationSearch. Conduit query methods should be driven by ApplicationSearch; it should be primarily responsible for reading parameters from the request, invoking the query, and retrieving results. In particular, saved ApplicationSearch queries should be queryable via API, and all ApplicationSearch capabilities should immediately be available in Conduit. The unique code in Conduit query calls should mostly be code for rendering objects into a wire format.

Use new API methods in arc tasks and arc list. Once the API exposes ApplicationSearch, we can rewrite arc tasks and arc list to be a thin layer of glue on top of the underlying API method. The unique code in these workflows should mostly be code for rendering objects in wire format (from Conduit) into text format (for display on the CLI).

This is a significant amount of work, largely because we have to convert a ton of existing SearchEngine and ConduitAPIMethod classes. Roughly:

  1. Drive ApplicationSearch through a field spec: 6 hours.
  2. Drive Conduit through ApplicationSearch: 8 hours.
  3. Drive arc tasks and arc list through modernized Conduit: 1 hour.

This work also probably can not take place in 15 contiguous hours, because step (2) causes huge API compatibility breaks. I do currently favor doing a major API break, but I'd like to do it at the same time we break everything we need to break for T5873, which I don't have a solid plan for yet.

  • From elsewhere, we should make it an explicit error to specify both "before" and "after". The behavior when both are specified is meaningless. This should generally be better documented.
eadler added a subscriber: eadler.
eadler moved this task from Backlog to Nice To Have on the FreeBSD board.Jun 14 2015, 4:39 AM
gabe awarded a token.Aug 13 2015, 11:00 PM
gabe added a subscriber: gabe.Aug 13 2015, 11:03 PM

The new *.edit and *.search endpoints are now available in Paste and Maniphest, so arc paste, arc todo, and arc tasks can switch over. I'm not necessarily planning to do this immediately -- at a minimum, I'm going to let them stabilize a bit first.

arc list can't switch until Differential moves to EditEngine, which is probably some ways away.

ox added a subscriber: ox.Dec 16 2015, 5:04 PM
epriestley moved this task from Backlog to API Changes on the Arcanist board.Jul 21 2016, 11:55 AM
eadler added a project: Restricted Project.Aug 5 2016, 5:23 PM