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

Separate parsing implementation from setter in SearchParseElement #6758

Closed
wants to merge 1 commit into from

Conversation

synhershko
Copy link
Contributor

This, in order to allow reuse of parsing logic by plugins or other internal parts.

Closes #3602

@s1monw
Copy link
Contributor

s1monw commented Jul 7, 2014

I took a quick look at this though and I think we should keep it simpler and just add a method

public  SearchContextHighlight parse(XContentParser parser, IndexQueryParserService queryParserService) {
// do your q parsing
}

and do this in implementations where is makes sense... I don't think we should do different exception handling at all just stick to what is in there for now and can you try to not make things static here. I also see that they are all private so I wonder how you access them?

@synhershko
Copy link
Contributor Author

The reason why I did the re-throwing with another exception is to still be able to throw SearchParseException with the context. I think it's valuable in the exception. If you think I can drop it, that would definitely be easier.

The static methods are factory methods, they should indeed be public, my bad.

@s1monw
Copy link
Contributor

s1monw commented Jul 7, 2014

fail enough... then lets go with ElasticsearchIllegalArgumentException

@synhershko
Copy link
Contributor Author

Done, I'll go ahead and apply this to all the things

@synhershko
Copy link
Contributor Author

Applied this in a few more places, however most implementations of SearchParseElement are either too simple for this change (a la VersionParseElement) or are too complex and will require serious refactoring (see SortParseElement for example).

I assume the question is do we want to go farther than where we are now in this PR?

context.fetchSourceContext(parseImpl(parser));
}

public static FetchSourceContext parseImpl(XContentParser parser) throws IOException {
Copy link
Contributor

Choose a reason for hiding this comment

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

can we name all those public void parse(XContentParser parser) and make them not static?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

the idea was to make those usable also without needing to instantiate an instance - what's wrong with statics?

Copy link
Contributor

Choose a reason for hiding this comment

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

you can not override them when you subclass which is a pita

Copy link
Contributor Author

Choose a reason for hiding this comment

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

fair point. As there are no injected ctors in this PR it does make sense to remove the statics, I'll update the PR

@s1monw
Copy link
Contributor

s1monw commented Jul 9, 2014

I left some comments... if this is enough for you we can just pull it without changing all the others

@s1monw
Copy link
Contributor

s1monw commented Jul 15, 2014

@synhershko any news on this?

@s1monw s1monw removed the review label Jul 15, 2014
@synhershko
Copy link
Contributor Author

@s1monw #6758 (comment)

@synhershko
Copy link
Contributor Author

@s1monw pushed fixes as per your comments

@s1monw
Copy link
Contributor

s1monw commented Jul 17, 2014

LGTM can you squash the commits

This, in order to allow reuse of parsing logic by plugins or other internal parts
@synhershko
Copy link
Contributor Author

@s1monw done

@synhershko
Copy link
Contributor Author

@s1monw ping, before this gets stale :)

@s1monw
Copy link
Contributor

s1monw commented Jul 28, 2014

thanks for the ping I will take care of it soon

@s1monw
Copy link
Contributor

s1monw commented Jul 28, 2014

I adjusted the commit msg and pushed to master & 1.x thanks @synhershko

@s1monw s1monw closed this Jul 28, 2014
@clintongormley clintongormley changed the title Separate parsing implementation from setter in SearchParseElement Internal: Separate parsing implementation from setter in SearchParseElement Sep 10, 2014
@clintongormley clintongormley changed the title Internal: Separate parsing implementation from setter in SearchParseElement Separate parsing implementation from setter in SearchParseElement Jun 7, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Separate parsing impl from setter in SearchParseElement
3 participants