This would appear to work, though the main problem is that the
memcache protocol specifies a key length of <250 characters, so it's
not really a good idea to send a sizable query request even in a URL
like that. My particular memcache client implementation crashes in
this case. I could try to use another, but I also think usage of
the memcache module should at least stick to the wire-level
constraints of the protocol.
Would there be opposition to me adding the CAS instruction as I
described? This will behave the same as a GET request but will use the
data provided. There's no real equivalent semantic for CAS (check-and-
set) in the HTTP protocol (this would be PUT with special headers for
validation, I guess) so it seems reasonable to co-opt its here to make
the API more complete. Do you agree?
On Nov 1, 12:14 pm, Shay Banon kim...@gmail.com wrote:
Its been a long time since I wrote the memcached module, but yes, you can
provide source as a URL parameter when you search. Though, I would suggest
using the HTTP transport, as its gone through a more thorough testings.
On Tue, Nov 1, 2011 at 8:54 PM, Greg Slovacek g...@asana.com wrote:
I'm evaluating ElasticSearch to see if its features and performance
will suit our needs for a search backend as we expand our search
product. First of all, congratulations on building a component that
was shockingly easy to get started with!
I'd like to use the memcached module to talk to our elastic search
backend since I can then drop it in place of our current one. This
leaves me with one question: how can I make a GET request that does a
Search other than a query_string search, given that I can't provide
post data? Is there an undocumented URL parameter (e.g. "source") I
can use that will contain the JSON post body?
Also, you might consider extending the module to support the CAS
command, which could be equivalent to a GET with a body. If we decide
to continue using elasticsearch via the memcache module I may be able
to help you guys with that.