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.
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 greg@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 Elasticsearch
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.
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?
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 Elasticsearch
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.
On Wed, Nov 2, 2011 at 1:29 AM, Greg Slovacek greg@asana.com wrote:
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?
I remember looking at CAS back when I wrote the memcached protocol, and it
did not fit a request that can both get a payload, and send a payload as a
response. But, I might have missed something, so definitely, I am open to
it.
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 Elasticsearch
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.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.
