Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update Scripting API to Store Context for Scripts #20621

Closed
wants to merge 40 commits into from

Conversation

jdconrad
Copy link
Contributor

@jdconrad jdconrad commented Sep 21, 2016

Change stored scripts/file scripts to take in a context, and ensure that context is available at compile-time as a precursor to this feature (#20426).

This is currently a WIP since it's a large change, and there's some way to go. I wanted to get early feedback on this portion.

The steps for this change are the following:

  • Modify stored scripts API to allow for context, store lang, and make the namespace only based on id.
  • Modify the file script API to allow for context, store lang, and make the namespace only based on id.
  • Update compilation by splitting the scripts into the 3 types of file, stored, and inline. Ensure that context is always passed in upon compilation.

Note any context currently passed in will not be used.  This is simply a
precursor to requiring context at compilation time.  This also changes
stored scripts to have a single namespace of id rather than lang/id.
The lang will now be retrieved from the stored script rather than
need to be passed in once the script is stored.
@jdconrad jdconrad added WIP :Core/Infra/Scripting Scripting abstractions, Painless, and Mustache v6.0.0-alpha1 v5.0.0 labels Sep 21, 2016
@nik9000
Copy link
Member

nik9000 commented Oct 4, 2016

I dropped v5.0.0 because it isn't making that release. I dropped breaking and added breaking-java because I expect this to break plugins and maybe the transport client a little but we'll have to get it in in a backwards compatible way so that we can backport it to the 5.x branch.

Copy link
Member

@nik9000 nik9000 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This has already gotten pretty large! I wonder if you can cut it into smaller PRs when it is closer to ready so we can review in smaller chunks.

boolean exists = in.readBoolean();

if (exists) {
source = StoredScriptSource.staticReadFrom(in);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it'd be more normal to do in.readOptionalWriteable and make sure StoredScriptSource is Writeable.

public int hashCode() {
return Objects.hash(lang, params, script, type, contentType);
public interface ScriptBinding {
Object compile(ScriptEngineService engine, String id, String code, Map<String, String> options);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be ScriptBinding<T> where T is the interface that we expect the script to implement? Then compile can return T?

ParseField SCRIPT = new ParseField("script");
ParseField LANG = new ParseField("lang");
ParseField PARAMS = new ParseField("params");
public static final class SearchScriptBinding implements ScriptBinding {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like this should be somewhere in the search infrastructure rather.

}

public static final String DEFAULT_SCRIPT_LANG = "painless";
public static final String DEFAULT_SCRIPT_NAME = "<inline>";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe rename to INLINE_SCRIPT_NAME?


public static final String CONTENT_TYPE_OPTION = "content_type";

private Script() {}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add a comment about why you need the empty private ctor?

@jdconrad
Copy link
Contributor Author

I'm going to separate out this change into smaller pieces. I'm going to close this for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>breaking-java :Core/Infra/Scripting Scripting abstractions, Painless, and Mustache WIP
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants