Script_fields for document GET requests

Elastic Stack Elasticsearch
1

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?

Andrew

2

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.

--
Ivan

On Wed, Feb 29, 2012 at 12:54 PM, Andrew Pendleton abpend@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?

Andrew

3

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.

--
Ivan

On Wed, Feb 29, 2012 at 12:54 PM, Andrew Pendleton <abpend@gmail.com (mailto:abpend@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?

Andrew

4

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?

Andrew

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.

--
Ivan

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?

Andrew

5

Yes, GET will be faster (though search will probably be fast enough), and I think the feature make sense.

On Thursday, March 1, 2012 at 5:25 PM, Andrew Pendleton wrote:

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?

Andrew

On Mar 1, 6:05 am, Shay Banon <kim...@gmail.com (http://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.

--
Ivan

On Wed, Feb 29, 2012 at 12:54 PM, Andrew Pendleton <abp...@gmail.com (mailto:abp...@gmail.com (http://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?

Andrew