esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Hirsch <>
Subject Re: Search questions
Date Fri, 01 Jan 2010 19:54:17 GMT
On Fri, Jan 1, 2010 at 8:30 PM, Ethan Jewett <> wrote:
> On Fri, Jan 1, 2010 at 12:33 PM, Richard Hirsch <> 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

>> 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:
>> - 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

View raw message