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.
Grabbing as discussed.
Assignee: james → erik
OS: Windows 7 → All
Hardware: x86_64 → All
This missed 9-13, and 9-20 :(. If this bug is assigned to you please retarget and take care of it ASAP.
Target Milestone: 2011-09-13 → 2011Q3
Does oedipus solve this? This is like a tracker and we probably already have one for it?
Target Milestone: 2011Q3 → 2011Q4
Actually, oedipus is one part of this, adding that tracker it as a dependency.
Depends on: 687912
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.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
No longer depends on: 687912
Resolution: --- → FIXED
Closed as [qa-]
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.