esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ethan Jewett <>
Subject Re: Search questions
Date Fri, 01 Jan 2010 19:30:32 GMT
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"?

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.

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

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


View raw message