Before I do: my usecase is that I have documents that contain an array
of several objects, each of which has a large (potentially mutli-
megabyte) text field on it, and I often want to retrieve one of these
objects from a particular document's array without incurring the
bandwidth expense of transferring the whole thing to the application
server. It seems, from further experimentation after I posted the
original message, that doing a search with an ID filter and a
script_field accomplishes what I was going for and is pretty fast. Do
you think a GET with a script_field would be faster enough (if that's
grammatical) to be worth the bother? Or should I be thinking about
doing this another way entirely?
On Mar 1, 6:05 am, Shay Banon kim...@gmail.com wrote:
Even if its in the transaction log, we still have access to the logs, so we can potentially support script_fields if there is a need. Open an issue?
On Thursday, March 1, 2012 at 2:39 AM, Ivan Brusic wrote:
My guess is since a GET request looks at both the index and the log
for a document, it is not able to compute a script field for when the
document only exists in the log. Just a guess.
On Wed, Feb 29, 2012 at 12:54 PM, Andrew Pendleton <abp...@gmail.com (mailto:abp...@gmail.com)> wrote:
I noticed that the search API has both a "fields" parameter for basic field
filtering and a "script_fields" parameter to do it programmatically. The
single-document GET api, though, only has "fields." Is there any particular
reason for this? If it's not fundamentally a bad idea, how hard would it be
to do via a plugin?