-
Notifications
You must be signed in to change notification settings - Fork 283
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
much better, flexible tag filters. change from json search templates to java api #146
Conversation
Added new RequestFactory
fixed a failing test
photon request factory done
photon request factory done
photon request factory done
photon request factory done
photon request factory done
photon request factory done
photon request factory done
photon request factory done
…. need to flesh out tests a little more.
… few more final tests.
… few more final tests.
Added new RequestFactory
fixed a failing test
photon request factory done
photon request factory done
photon request factory done
photon request factory done
Looks like a big refactoring, nice :) ! Did you already test this in production? Some questions:
|
…rch jsons for base search and location bias search
Yes, it is sort of a big refactor. I understand your concern about testing it in production. However, what do you mean by "production"? My production is not busy enough for a good test, so, the answer is no. However:
Let me know what you think about testing this. I do understand what you are asking for. |
So you know that no code was lost: there was some custom coding in the Searcher.java that I have taken out into separate classes. Here those are: |
Please don't take it as critique :), it is a really nice effort as the combinating-template strategy is a lot more error prone IMO. Regarding the Lucense-parsing: there is an ElasticSearch query which supports this, although this query type cannot be used as direct user input it is really nice to do simple filtering and arbitrary combinations. |
No, not taking as a critique. :) OK, I saw the link you sent. I will read some more and try to learn. For now, this pull request simply replicates what was in the json template. That way, there are fewer changes to test. You know what I mean? |
try { | ||
Double lon = Double.valueOf(webRequest.queryParams("lon")); | ||
Double lat = Double.valueOf(webRequest.queryParams("lat")); | ||
locationForBias = new GeometryFactory(new PrecisionModel(), 4326).createPoint(new Coordinate(lon, lat)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there is no need to create a geometry factory for every request, i can be a static final field
cool that's a big pull request with a lot of refactoring! I left some commands and maybe found a bug... I see logic got separated which is a step forward. You are right, it makes testing much easier. |
…If no results are found, then do a lenient search. Added javadoc to explain the filter states in PhotonQueryBuilder Made the GeometryFactory to be private final static instead of being a local variable.
You are right @christophlingg about the bug. I committed a fix with changes to the unit test. I also made the geometryfactory private static final. added some java docs. The difference between ConvertToJson and ConvertToGeoJson is that ConvertToJson converts SearchHits to a list of JSON objects. ConvertToGeoJson then converts to geojson format. This follows the exact pattern of code in Searcher and RequestHandler before refactoring. The Searcher class first converts SearchHits to a json and then operates on it to remove dupes etc. Then, in the RequestHandler, there are a few more lines of code to convert into GeoJson. I wanted to keep those lines of code as is, so, I simply replicated everything - except in different classes instead of private methods. Thanks for your words. I am glad that you and @karussell feel that this is a good refactor and a step forward. I am also glad that you feel that this makes testing much easier. Let me know how this looks. Looking forward to this getting into production on your website! :-) |
If there is anything else you have questions about, please ask. I will be happy to change code if you find issues or have concerns. |
sorry @sdole , at the moment i am quite busy. i'll make an 0.2.2 release tomorow |
Absolutely no worries. Thanks for the reply.
On Wed, Mar 4, 2015 at 12:28 PM -0800, "Christoph Lingg" notifications@github.com wrote: sorry @sdole , at the moment i am quite busy. i'll make an 0.2.2 release tomorow — |
much better, flexible tag filters. change from json search templates to java api
Here are the fixes/improvements:
To follow the path of code/instructions, look at lines 139 to 143 of App.java. The old Searcher is now deprecated, but not deleted. The replacement is SearchRequestHandler. This in turn has "Factory" classes that instantiate the required handlers to execute searches instead of direct dependency on concrete implementations. There are three steps to a search. First is to convert the native spark web request into a PhotonRequest object. During this step, we get the opportunity to validate the incoming request and do any defaults etc. Second step is to optionally setup a tag filter. Finally, the last step is to execute an Elasticsearch search.
I have also added unit tests.
All of the Elasticsearch API setup is in class PhotonQueryBuilder