Refactors MoreLikeThisQueryBuilder and Parser#13486
Refactors MoreLikeThisQueryBuilder and Parser#13486alexksikes wants to merge 10 commits intoelastic:feature/query-refactoringfrom
Conversation
|
@alexksikes can you rebase this to latest - there are quite some changes here that are now gone |
Relates to elastic#10217 This PR is against the query-refactoring branch. Closes elastic#13486
9c1a75c to
d722c47
Compare
|
@s1monw You can take a look now. Thank you. |
There was a problem hiding this comment.
I don't think we should allow null here I think this should throw an exception if null is passed in
There was a problem hiding this comment.
In fact, given that we require either doc or an index document id, this should really be a constructor and this setter should be removed. That way the user can only specify doc OR id and must specify one of them. We should add null checks in the constructors and throw IllegalArgumentException if nulls are passed in
There was a problem hiding this comment.
Also, given that type and index are required if id is specified we should remove the setters for type, id and index and remove the zero-arg constructor for Item so the user is forced to correct initialise the object with either the index, type and id, or the index, type and doc
There was a problem hiding this comment.
There is a constructor for doc. However, we do have this method for bwc, so maybe we should keep it?
Concerning null index, or type, this is so that these could be initialized by the search context, and we only have this context when the query is actually being created.
There was a problem hiding this comment.
We don't need to keep the constructors/methods for bwc. For the Java API we are able to break backwards compatibility here and we should if it makes the use of the API less trappy (as it does here).
There was a problem hiding this comment.
OK then if we are allowed to break bwc, then I much prefer to remove this method. That would simplify things from code and user perspective. A definite +1.
|
@alexksikes I left some comments. I also think someone else will need to quickly look before its merged as I have no experience of the MLT query |
|
@colings86 Thanks for the review. I'll address the comments on the next round of review. |
There was a problem hiding this comment.
Comment seems wrong, as far as I can see the difference to writeStringArrayNullable is that it writes boolean instead of int in case of null argument.
There was a problem hiding this comment.
why is this method needed if we have writeStringArrayNullable?
There was a problem hiding this comment.
That one doesn't seem to differentiate between null and zero-length array, which we need if we e.g. test for equality of queries after serialization. At least that's what I think, @Ale might have had other reasons.
There was a problem hiding this comment.
This exactly the reason. I first tried writeStringArrayNullable, but then you read back an empty array, not a null array.
There was a problem hiding this comment.
I'm not a fan of having both of these methods. The difference between them is too subtle. I think we should instead replace writeStringArrayNullable with writeOptionalStringArray as the former is trappy and could easily lead to bugs. Serialisation code should always serialise and de-serialise to the same thing.
There was a problem hiding this comment.
+1 should this change be part of this PR? Looks like this is not used anywhere else.
There was a problem hiding this comment.
If it's not used anywhere else (or even if its only used in a couple of places) then I would be +1 to doing it in this PR
There was a problem hiding this comment.
My bad this is actually used in a couple of places. I'll open an issue on this.
|
@alexksikes I did a round of reviews, given the amount of complexity in constructing the final MLT query I didn't check the internals of the helper methods moved over from the parsers, maybe those can be simplified later but as far as separating the toQuery/fromXContent I think this is good. Maybe someone else should have final look after you adressed the last comments. |
|
@cbuescher @colings86 I addressed all the comments. Should I do the package change for the Item class as part of this PR too? Thanks again for the review. |
There was a problem hiding this comment.
can we check the value we are reading here? an assertion would be ok
|
I left some minor comments LGTM otherwise |
Relates to #10217
This PR is against the query-refactoring branch.