[GitHub] [lucene-solr] dsmiley commented on issue #824: LUCENE-8755: QuadPrefixTree robustness
dsmiley commented on issue #824: LUCENE-8755: QuadPrefixTree robustness URL: https://github.com/apache/lucene-solr/pull/824#issuecomment-521022106 Any concerns/questions on the commit I added @chenkovsky ? BTW this is the first time I used a feature of GitHub that allows me (a member of this repo) to commit to the source branch of someone's PR. Pretty cool for collaboration. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on issue #824: LUCENE-8755: QuadPrefixTree robustness
dsmiley commented on issue #824: LUCENE-8755: QuadPrefixTree robustness URL: https://github.com/apache/lucene-solr/pull/824#issuecomment-519654862 > Does the indexed data contain luncene version info which created the index? If it contains, We can use old code to search in old indexed data. It does contain the version of Lucene, but not the Version used in analysis components (see class Version.java). In a sense the SpatialStrategy impls play the role of an analysis component & more). In order for a user of Lucene (e.g. Solr and it's users) to be able to use an existing index when they upgrade Lucene, a user can configure a specific version for analysis components consistent with the version that was used to write the index (will get set on an Analyzer.setVersion(...). If this is Solr, then this is set via luceneMatchVersion; raw Lucene usage requires explicit control here. There has yet to be a SpatialStrategy that tweaked it's operation based on the Version; the only change or two that comes to mind were backwards compatible (e.g. fewer needless terms). So there's no trace of Version usage in spatial-extras as of yet. I know this is kinda a pain to concern yourself with. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on issue #824: LUCENE-8755: QuadPrefixTree robustness
dsmiley commented on issue #824: LUCENE-8755: QuadPrefixTree robustness URL: https://github.com/apache/lucene-solr/pull/824#issuecomment-519303495 Thanks for the PR! Just curious; did you encounter this problem and thus were motivated to fix it? I didn't spend much time on it tonight, but it looks pretty good, and it has a cleaner appearance that reads better to me. You did remove a comment or two that are still appropriate, like the link to Z-order. Did you run Lucene spatial-extras tests? "ant precommit"? I suspect a tokenization change ought to be toggled by Version, similar to some other behavior changes in Lucene analyzers. And that means finding a way for the old tokenization and the new-one to co-exist, plus a means to communicate that choice -- probably via `org.apache.lucene.spatial.prefix.tree.SpatialPrefixTreeFactory#init`. If we don't do this, then some use-cases with existing indexes may break, like exact point lookup of itself should round-trip. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
