675693 - Internal Search API redesign

Status: VERIFIED FIXED

(support.mozilla.org :: Code Quality, task)

Description

[James Socol [:jsocol, :james]]

Everyone who has had to touch search knows it sucks, internally. (I can be blunt because I'm the one who designed it. <tenth-doctor>I'm sorry, I'm so sorry.</tenth-doctor>)

In order to make ripping the guts (sphinx) out of search possible, step one is going to be fixing the internal API. This is the workflow I'm envisioning here:

1. Evaluate current and obvious future use cases and goals (Include UX).
2. Design new API.
3. Implement (at least currently-necessary parts of) new API *alongside current API*.
4. Move pieces of functionality over to new API.
5. Make search provider/backend easy to swap.
6. Start replacing search provider. (Waffily?)

Goals for a new API:

* Be Djangoy/Pythonic.
* Move defaults into search clients.
* SHORTER omg SHORTER to use.
* Abstract filter structures away from callers.
* Provide high-level "Find me stuff" access.

Comment 1

[Erik Rose [:erik][:erikrose]]

Grabbing as discussed.

Comment 2

[James Socol [:jsocol, :james]]

This missed 9-13, and 9-20 :(. If this bug is assigned to you please retarget and take care of it ASAP.

Comment 3

[Ricky Rosario [:rrosario, :r1cky]]

Does oedipus solve this? This is like a tracker and we probably already have one for it?

Comment 4

[Ricky Rosario [:rrosario, :r1cky]]

Actually, oedipus is one part of this, adding that tracker it as a dependency.

Comment 5

[Erik Rose [:erik][:erikrose]]

This doesn't really have any value as a tracker. If you want to follow something, follow the ElasticSearch tracker, which covers all the remaining work: bug 694979.

Comment 6

[Rebecca Billings [:rbillings]]

Closed as [qa-]