API support for searching from the record selector

[seancolsen]

Problem

• The Record Selector needs to search across multiple columns and return a response fast-enough to provide good UX within an auto-complete.

Special cases to consider

Query split across multiple columns

• A person table has the following data

  id	first_name	last_name
  101	Emma	Watson
  102	Emma	Stone

• The user has configured first_name and last_name as the preview columns for all records selectors which reference the person table.

• Within a person record selector, the user enters the text "Emma Stone" and expects to see record 102 in the results.

Records that contain a lot of data

• A table might have columns with large blobs of text. For network performance, the results returned to the record selector should ideally be as minimal as possible, containing only the fields that the record selector needs to display and nothing more.

Solution

• It seems like the easiest solution would be to set up a new API endpoint for this, perhaps at something like /api/v0/tables/<id>/record_previews/. The fields returned by this endpoint would be determined by table preferences set in API support for storing "record preview" and "record selector" settings #944.
• The implementer should write a proposed API spec and get feedback from other members of the engineering team before implementing this issue.

Additional context

• Blocked by API support for storing "record preview" and "record selector" settings #944
• Foreign Key Spec -- Scenario 5

Prior thoughts on solution

These are @seancolsen's original thoughts on API design, preserved here for consideration by the implementer.

• Use the records API.
  • It may be sufficient as-is. After API support for storing "record preview" and "record selector" settings #944 is implemented, the front will be able to know all the columns that the search should target. It might be able to construct a suitable request to the records API, especially if we only want to support very simplistic searching. If so, we can close this ticket.
  • It seems to me that the "Query split across multiple columns" case above will be difficult with the records API as-is though.
  • If the records API could handle this use-case with minor alterations, then we can use this ticket to track that work.
• Creating new endpoint may be worth considering.

I'm not sure of the best approach.

[seancolsen]

@kgodey I'm assigning this to you to help solidify an approach and loop others in as needed.

[kgodey]

Updated description with details of approach.

[silentninja]

Fixed by #1449