On Fri, Jan 1, 2010 at 8:30 PM, Ethan Jewett <[email protected]> wrote: > On Fri, Jan 1, 2010 at 12:33 PM, Richard Hirsch <[email protected]> wrote: > >> Are you thinking of adding search to the new api indirectly - which I >> prefer- or directly with a "search" method? > > I'm not sure I understand what you mean be "directly" and "indirectly". > > My initial goal was to be able to implement a relatively flexible > "search" method that would allow for a search on any searchable > property or combination (and/or) of searchable properties. I think > that's probably what you mean by "directly". > > I also see an opportunity to replace the non-streaming parts of things > like the api2/user/messages (for example > api2/user/messages?history=300 << ouch) with a call to the > Lucene/Compass index. There is still a call to Messages.findMessages, > but at least we wouldn't be doing search queries on the messages DB. I > take is that's what you mean by "indirectly"?
This is what I meant by indirectly. > > Do you think it would make sense to go with purely incorporating > search into the existing API methods as filter parameters on the > message endpoints in api2? For example GET > /api2/user/messages?history=20&filter_tags=esme,api (returns the last > 20 messages in the user's timeline tagged with "esme" and "api") I'm > not sure what the syntax would be here, but I'll think about it and > I'll have a look at other search APIs. Exactly. I think that the search should be hidden in the existing API http://apiwiki.twitter.com/Twitter-Search-API-Method%3A-search > >> Probably a local problem. I haven't tried search on the stax instance >> for a while. If desired, I could restart the server. > > Not a big deal. I just wanted to make sure that there isn't something > broken about search in general, only with that server. > >> The search functionality was conceived before we started pools. Thus, >> pools weren't include back then. I'd like to think that search in >> pool would be useful. What about searching across all "my" pools or a >> certain pool? > > I see that from looking at the code now (thanks for pointing me > there!). I think adding pool as a searchable property should be done, > and I can definitely do that. What I'm not clear on is if this will > break the existing search index in some way, so maybe someone who > knows a lot more about the search than me can guide me here. easiest way would be to try and then see if search still works. > >> Look here for the current search implementation: >> http://svn.apache.org/viewvc/incubator/esme/trunk/server/src/main/scala/org/apache/esme/model/Message.scala?view=markup >> - starting on line 148 > > Thanks for the pointer. Looks like tags are already indexed, so we can > do an arbitrary search query based only on tags. Awesome! I'll try > this out soon-ish to make sure. > > Ethan >
