Scripting Fields API for reading

[stu-elastic]

Add the read API

Field<T> interface
Represents a field that may or may not exist within a document.

• String getName()
  Returns the name of the field.

• boolean isEmpty()
  Checks if at least one value exists.

• T getValue(T defaultValue)
  Returns the first value, if exists, otherwise returns defaultValue. This may access the first indexed value, or the document source if the field is not indexed and the source is available.

• List<T> getValues()
  Returns values of the field, as if they were indexed. This may access indexed values, or the document source if the field is not indexed and the source is available.

• boolean hasValue(Predicate<T> predicate) (post 8.1.0)
  Returns true if exactly one value exists and that value matches the specified predicate, otherwise false.

• boolean containsValue(Predicate<T> predicate) (post 8.10)
  Returns true if any value matches the specified predicate, otherwise false.

[elasticmachine]

Pinging @elastic/es-core-infra (Team:Core/Infra)

[rjernst]

Other than getName and isEmpty, I wonder if the other methods should be duck-typed. For example, on IntField, it would make sense to have hasValue take IntPredicate, ie use primitive based types where possible.

[jdconrad]

I think getValue and getValues continues to be necessary unless we are targeting this API only as Painless. But for other possible scripting plugins to have access to the fields API these methods are important.

[nemphys]

I just implemented a ScriptEngine plugin using the getValues() method 2 days ago, only to discover that both getValue() and getValues() have been removed in 7.16.0 (!).

I am now trying to figure out how to gain access to the document values; the DocReader interface still has "Access the document in a script, provides both old-style, doc['fieldname'], and new style field('fieldname') access to the fields" in the comments, which is the reason why I decided to use the "new style" field() method in the first place.

Should I revert to using DocReader's doc/docAsMap, or is there a better way I haven't managed to find?

[jdconrad]

@nemphys For now targeting the old style doc is going to be the best path forward. The scripting fields API isn't considered GA, yet, and will likely have more changes coming forth that break your work, unfortunately.

Out of my own curiosity, if you don't mind sharing, a few other questions:

• does your plugin use dynamic types?
• What's your casting model look like?
• How you process the data you get back from doc right now.

[nemphys]

@jdconrad Thank you for the heads up (though I suppose adding some relevant comments to the code itself wouldn't hurt, since there is no actual documentation for this stuff and one can only try to guess around at the moment :-) ).

My plugin is adjusting score values based on rules passed to the script as parameters (containing field names and what to do if the doc value matches a condition). Since specific rules apply to specific field types, the only casting I am doing to the List<?> returned by getValues() is to String/Number, which works without surprises (since I am certain that the actual values will be of these types; some sanity checks added for peace of mind).

I am currently trying to figure out how to do the same using .doc(); I am still unable to actually debug this, since v 7.16.0 is not available through Homebrew yet.

Since this is a young project, I would like to use a method that will be around for the forseeable future, though. Do you think .doc() is the way to go?

[stu-elastic]

@nemphys doc['fieldname'] is stable and supported. The fields api is the future but as @jdconrad mentioned, it is not GA and subject to change.

[stu-elastic]

• We should allow users to determine the source of the field and include missing.