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

much better, flexible tag filters. change from json search templates to java api #146

Merged
merged 63 commits into from
Mar 6, 2015

Conversation

sdole
Copy link
Contributor

@sdole sdole commented Feb 28, 2015

Here are the fixes/improvements:

  1. tag filter now supports multiple ways of filtering. inclusions, exclusions by tag, key, value and combinations of those. So, in theory, one can be very very specific in filtering search criteria.
  2. New code no longer uses the json template based search criteria mechanism. Instead, it uses ES Java api.
  3. Code is now a little more spread out into multiple classes instead of being in private methods in a handful of classes - IMO: this improves testability of code, makes it extensible, and also makes it less prone to bugs.
  4. Readme has an updated description.

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

ec2-user added 30 commits February 14, 2015 16:52
Added new RequestFactory
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
Added new RequestFactory
photon request factory done
photon request factory done
photon request factory done
photon request factory done
@karussell
Copy link
Collaborator

Looks like a big refactoring, nice :) !

Did you already test this in production?

Some questions:

  • What is the difference between BaseElasticsearchSearcher and BasePhotonSearcher?
  • Did you thought about avoiding the parsing code and just use a Lucene parser? (to get even more powerful queries)
  • Also there is still this System.out.println(query);
  • Why did you uncomment the TagFilterQueryBuilderTest only? Is it not fully replaced or replacable?

ec2-user added 2 commits March 1, 2015 17:18
@sdole
Copy link
Contributor Author

sdole commented Mar 1, 2015

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:

  1. I did test from a browser ("/api") against the index file I downloaded from komoot. Do you have test cases that I can manually execute against photon? I searched using my requirements and it looked fine.
  2. I brought back part of TagFilterQueryBuilderTest which you mentioned in your point 4. This now has a test comparing the java output to the erstwhile json template. So, it might be worthwhile to compare the files src/test/resources/json_queries to the file /es/query.json
  3. Further, I have a test named TagFilterQueryBuilderSearchTest that runs through a few test scenarios and those seem to work fine too.
  4. That System.out.println() was added to searcher when I started work to see what the final json looked like before I started work. I forgot to remove it and did not notice it because it was not being executed. I have taken it out now and if you compare the fork vs master, you will notice that the only line changed is @deprecated at the top.
  5. About the difference between BaseElasticsearchSearcher and BasePhotonSearcher: I have removed BasePhotonSearcher. It was not being used.
  6. About avoiding the parsing code... I have not idea how to do that... To be honest, I am very new to elasticsearch and indexing in general, I would not know where to start... Its only because photon already exists that I am able to refactor... creating this from scratch is a whole another universe for me.

Let me know what you think about testing this. I do understand what you are asking for.

@sdole
Copy link
Contributor Author

sdole commented Mar 2, 2015

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:

  1. StreetDupesRemover
  2. ConvertToGeoJson

@karussell
Copy link
Collaborator

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.

@sdole
Copy link
Contributor Author

sdole commented Mar 2, 2015

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));
Copy link
Member

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

@christophlingg
Copy link
Member

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.
@sdole
Copy link
Contributor Author

sdole commented Mar 3, 2015

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! :-)

@sdole
Copy link
Contributor Author

sdole commented Mar 4, 2015

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.

@christophlingg
Copy link
Member

sorry @sdole , at the moment i am quite busy. i'll make an 0.2.2 release tomorow

@sdole
Copy link
Contributor Author

sdole commented Mar 4, 2015

Absolutely no worries. Thanks for the reply.

    Sent by Outlook for Android

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


Reply to this email directly or view it on GitHub.

christophlingg added a commit that referenced this pull request Mar 6, 2015
much better, flexible tag filters. change from json search templates to java api
@christophlingg christophlingg merged commit 96bd7e4 into komoot:master Mar 6, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants