[jira] [Closed] (SOLR-2155) Geospatial search using geohash prefixes
[
https://issues.apache.org/jira/browse/SOLR-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley closed SOLR-2155.
--
Resolution: Won't Fix
> Geospatial search using geohash prefixes
>
>
> Key: SOLR-2155
> URL: https://issues.apache.org/jira/browse/SOLR-2155
> Project: Solr
> Issue Type: Improvement
>Reporter: David Smiley
>Assignee: David Smiley
> Attachments: GeoHashPrefixFilter.patch, GeoHashPrefixFilter.patch,
> GeoHashPrefixFilter.patch,
> SOLR-2155_GeoHashPrefixFilter_with_sorting_no_poly.patch, SOLR.2155.p3.patch,
> SOLR.2155.p3tests.patch, Solr2155-1.0.2-project.zip,
> Solr2155-1.0.3-project.zip, Solr2155-1.0.4-project.zip,
> Solr2155-for-1.0.2-3.x-port.patch
>
>
> {panel:title=NOTICE} The status of this issue is a plugin for Solr 3.x
> located here: https://github.com/dsmiley/SOLR-2155. Look at the introductory
> readme and download the plugin .jar file. Lucene 4's new spatial module is
> largely based on this code. The Solr 4 glue for it should come very soon but
> as of this writing it's hosted temporarily at https://github.com/spatial4j.
> For more information on using SOLR-2155 with Solr 3, see
> http://wiki.apache.org/solr/SpatialSearch#SOLR-2155 This JIRA issue is
> closed because it won't be committed in its current form.
> {panel}
> There currently isn't a solution in Solr for doing geospatial filtering on
> documents that have a variable number of points. This scenario occurs when
> there is location extraction (i.e. via a "gazateer") occurring on free text.
> None, one, or many geospatial locations might be extracted from any given
> document and users want to limit their search results to those occurring in a
> user-specified area.
> I've implemented this by furthering the GeoHash based work in Lucene/Solr
> with a geohash prefix based filter. A geohash refers to a lat-lon box on the
> earth. Each successive character added further subdivides the box into a 4x8
> (or 8x4 depending on the even/odd length of the geohash) grid. The first
> step in this scheme is figuring out which geohash grid squares cover the
> user's search query. I've added various extra methods to GeoHashUtils (and
> added tests) to assist in this purpose. The next step is an actual Lucene
> Filter, GeoHashPrefixFilter, that uses these geohash prefixes in
> TermsEnum.seek() to skip to relevant grid squares in the index. Once a
> matching geohash grid is found, the points therein are compared against the
> user's query to see if it matches. I created an abstraction GeoShape
> extended by subclasses named PointDistance... and CartesianBox to support
> different queried shapes so that the filter need not care about these details.
> This work was presented at LuceneRevolution in Boston on October 8th.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-1718) Carriage return should submit query admin form
[ https://issues.apache.org/jira/browse/SOLR-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley closed SOLR-1718. -- Resolution: Won't Fix > Carriage return should submit query admin form > -- > > Key: SOLR-1718 > URL: https://issues.apache.org/jira/browse/SOLR-1718 > Project: Solr > Issue Type: Improvement > Components: web gui >Affects Versions: 1.4 >Reporter: David Smiley >Priority: Minor > Attachments: SOLR-1718_default_search_screen.patch > > > Hitting the carriage return on the keyboard should submit the search query on > the admin front screen. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-435) QParser must validate existence/absence of "q" parameter
[
https://issues.apache.org/jira/browse/SOLR-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley closed SOLR-435.
-
Resolution: Fixed
Re-committed to 4.x, and I moved the CHANGES.txt from the v4 to v3 section on
both branches. Closing issue.
> QParser must validate existence/absence of "q" parameter
>
>
> Key: SOLR-435
> URL: https://issues.apache.org/jira/browse/SOLR-435
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: 1.3
>Reporter: Ryan McKinley
>Assignee: David Smiley
> Fix For: 3.6, 4.0
>
> Attachments:
> SOLR-2001_3x_backport_with_empty_string_check_and_test.patch, SOLR-435.patch,
> SOLR-435_3x_consistent_errors.patch, SOLR-435_q_defaults_to_all-docs.patch
>
>
> Each QParser should check if "q" exists or not. For some it will be required
> others not.
> currently it throws a null pointer:
> {code}
> java.lang.NullPointerException
> at org.apache.solr.common.util.StrUtils.splitSmart(StrUtils.java:36)
> at
> org.apache.solr.search.OldLuceneQParser.parse(LuceneQParserPlugin.java:104)
> at org.apache.solr.search.QParser.getQuery(QParser.java:80)
> at
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:67)
> at
> org.apache.solr.handler.SearchHandler.handleRequestBody(SearchHandler.java:150)
> ...
> {code}
> see:
> http://www.nabble.com/query-parsing-error-to14124285.html#a14140108
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-2155) Geospatial search using geohash prefixes
[
https://issues.apache.org/jira/browse/SOLR-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley closed SOLR-2155.
--
Resolution: Won't Fix
> Geospatial search using geohash prefixes
>
>
> Key: SOLR-2155
> URL: https://issues.apache.org/jira/browse/SOLR-2155
> Project: Solr
> Issue Type: Improvement
>Reporter: David Smiley
> Attachments: GeoHashPrefixFilter.patch, GeoHashPrefixFilter.patch,
> GeoHashPrefixFilter.patch,
> SOLR-2155_GeoHashPrefixFilter_with_sorting_no_poly.patch, SOLR.2155.p3.patch,
> SOLR.2155.p3tests.patch, Solr2155-1.0.2-project.zip,
> Solr2155-1.0.3-project.zip, Solr2155-1.0.4-project.zip,
> Solr2155-for-1.0.2-3.x-port.patch
>
>
> {panel:title=NOTICE} There is a .zip attached to the issue with a .jar you
> can drop in to Solr 3.x. Lucene 4's new spatial module is largely based on
> this code. The Solr 4 glue for it should come very soon but as of this
> writing it's hosted temporarily at Spatial4j.com. For more information on
> using SOLR-2155 with Solr 3, see
> http://wiki.apache.org/solr/SpatialSearch#SOLR-2155 This JIRA issue is
> closed because it won't be committed in its current form.
> {panel}
> There currently isn't a solution in Solr for doing geospatial filtering on
> documents that have a variable number of points. This scenario occurs when
> there is location extraction (i.e. via a "gazateer") occurring on free text.
> None, one, or many geospatial locations might be extracted from any given
> document and users want to limit their search results to those occurring in a
> user-specified area.
> I've implemented this by furthering the GeoHash based work in Lucene/Solr
> with a geohash prefix based filter. A geohash refers to a lat-lon box on the
> earth. Each successive character added further subdivides the box into a 4x8
> (or 8x4 depending on the even/odd length of the geohash) grid. The first
> step in this scheme is figuring out which geohash grid squares cover the
> user's search query. I've added various extra methods to GeoHashUtils (and
> added tests) to assist in this purpose. The next step is an actual Lucene
> Filter, GeoHashPrefixFilter, that uses these geohash prefixes in
> TermsEnum.seek() to skip to relevant grid squares in the index. Once a
> matching geohash grid is found, the points therein are compared against the
> user's query to see if it matches. I created an abstraction GeoShape
> extended by subclasses named PointDistance... and CartesianBox to support
> different queried shapes so that the filter need not care about these details.
> This work was presented at LuceneRevolution in Boston on October 8th.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-2724) Deprecate defaultSearchField and defaultOperator defined in schema.xml
[ https://issues.apache.org/jira/browse/SOLR-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley closed SOLR-2724. -- Resolution: Fixed I committed to 3x & 4x. Closing issue. > Deprecate defaultSearchField and defaultOperator defined in schema.xml > -- > > Key: SOLR-2724 > URL: https://issues.apache.org/jira/browse/SOLR-2724 > Project: Solr > Issue Type: Improvement > Components: Schema and Analysis, search >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Fix For: 3.6, 4.0 > > Attachments: > SOLR-2724_deprecateDefaultSearchField_and_defaultOperator.patch > > Original Estimate: 2h > Remaining Estimate: 2h > > I've always been surprised to see the element and > defined in the schema.xml file since > the first time I saw them. They just seem out of place to me since they are > more query parser related than schema related. But not only are they > misplaced, I feel they shouldn't exist. For query parsers, we already have a > "df" parameter that works just fine, and explicit field references. And the > default lucene query operator should stay at OR -- if a particular query > wants different behavior then use q.op or simply use "OR". > Seems like something better placed in solrconfig.xml than in the > schema. > In my opinion, defaultSearchField and defaultOperator configuration elements > should be deprecated in Solr 3.x and removed in Solr 4. And > should move to solrconfig.xml. I am willing to do it, provided there is > consensus on it of course. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-435) QParser must validate existence/absence of "q" parameter
[
https://issues.apache.org/jira/browse/SOLR-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley closed SOLR-435.
-
Resolution: Fixed
I committed the patch to 3x and made the small improvements to 4x.
> QParser must validate existence/absence of "q" parameter
>
>
> Key: SOLR-435
> URL: https://issues.apache.org/jira/browse/SOLR-435
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: 1.3
>Reporter: Ryan McKinley
>Assignee: David Smiley
> Fix For: 3.6, 4.0
>
> Attachments:
> SOLR-2001_3x_backport_with_empty_string_check_and_test.patch, SOLR-435.patch,
> SOLR-435_3x_consistent_errors.patch, SOLR-435_q_defaults_to_all-docs.patch
>
>
> Each QParser should check if "q" exists or not. For some it will be required
> others not.
> currently it throws a null pointer:
> {code}
> java.lang.NullPointerException
> at org.apache.solr.common.util.StrUtils.splitSmart(StrUtils.java:36)
> at
> org.apache.solr.search.OldLuceneQParser.parse(LuceneQParserPlugin.java:104)
> at org.apache.solr.search.QParser.getQuery(QParser.java:80)
> at
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:67)
> at
> org.apache.solr.handler.SearchHandler.handleRequestBody(SearchHandler.java:150)
> ...
> {code}
> see:
> http://www.nabble.com/query-parsing-error-to14124285.html#a14140108
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-3270) edismax throws exception with q having just whitespace
[ https://issues.apache.org/jira/browse/SOLR-3270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley closed SOLR-3270. -- Resolution: Fixed Fix Version/s: 4.0 3.6 Committed to 3.6 & trunk a minute ago. > edismax throws exception with q having just whitespace > -- > > Key: SOLR-3270 > URL: https://issues.apache.org/jira/browse/SOLR-3270 > Project: Solr > Issue Type: Bug >Affects Versions: 3.5 >Reporter: David Smiley >Assignee: David Smiley > Fix For: 3.6, 4.0 > > Attachments: SOLR-3270_edismax_blank_q_bug.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-2617) Support git.
[ https://issues.apache.org/jira/browse/SOLR-2617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley closed SOLR-2617. -- Resolution: Fixed Fix Version/s: 4.0 3.6 Assignee: David Smiley > Support git. > > > Key: SOLR-2617 > URL: https://issues.apache.org/jira/browse/SOLR-2617 > Project: Solr > Issue Type: New Feature > Components: Build >Reporter: David Smiley >Assignee: David Smiley > Fix For: 3.6, 4.0 > > > Apache has git mirrors of Lucene/Solr, as well as many other projects. > Presently, if git is used to checkout Lucene/Solr, there are only a couple > small problems to address, but it otherwise works fine. > * a .gitignore is needed. > * empty directories need to be dealt-with. (git doesn't support them) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-2854) Load URL content stream on-demand, rather than automatically
[ https://issues.apache.org/jira/browse/SOLR-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley closed SOLR-2854. -- Resolution: Fixed I committed the 3x backport in r1293115. > Load URL content stream on-demand, rather than automatically > > > Key: SOLR-2854 > URL: https://issues.apache.org/jira/browse/SOLR-2854 > Project: Solr > Issue Type: Improvement >Reporter: David Smiley >Assignee: Erik Hatcher > Labels: security > Fix For: 3.6, 4.0 > > Attachments: SOLR-2854-delay-stream-opening.patch, > SOLR-2854-extract_fix.patch, SOLR-2854_branch_3x_remote_streaming_fix.patch, > SOLR-2854_test_remote_streaming_not_done_on_select.patch > > > I think the remote streaming feature should be limited to update request > processors. I'm not sure if there is even any use of using it on a /select, > but even if there is, it's an unintended security risk. Observe this URL > that is roughly the equivalent of an SQL injection attack: > http://localhost:8983/solr/select?q=*:*&indent=on&wt=ruby&rows=2&stream.url=http%3A%2F%2Flocalhost%3A8983%2Fsolr%2Fupdate%3Fcommit%3Dtruetream.body%3D%3Cdelete%3E%3Cquery%3E*%3A*%3C%2Fquery%3E%3C%2Fdelete%3E > Yep; that's right -- this *search* deletes all the data in your Solr > instance! If you blocked off access to /update* based on IP then that isn't > good enough. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-3040) Avoid use of qt param for the DIH in the admin UI
[
https://issues.apache.org/jira/browse/SOLR-3040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley closed SOLR-3040.
--
Resolution: Fixed
Fix Version/s: 4.0
3.6
Assignee: David Smiley
Committed branch_3x: r1293105 trunk: r1293102
CHANGES.txt entry underneath upgrade instructions:
{noformat}
* SOLR-3040: The DIH's admin UI (dataimport.jsp) now requires
DIH request handlers to start with a '/'. (dsmiley)
{noformat}
FYI it turned out that in the span of time since when I did the first patch and
when I committed now, the new admin UI already gained this limitation (leading
'/' required). Wether deliberate or accidental, I'm glad.
> Avoid use of qt param for the DIH in the admin UI
> -
>
> Key: SOLR-3040
> URL: https://issues.apache.org/jira/browse/SOLR-3040
> Project: Solr
> Issue Type: Improvement
> Components: web gui
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 3.6, 4.0
>
> Attachments: SOLR-3040_avoid_qt_for_DIH_in_admin_ui.patch
>
>
> I really, really dislike that the qt parameter can used to refer to request
> handlers starting with a '/', _especially_ for non-search handlers. The
> admin UI has one place I am aware of that attempts to do this, which is the
> DIH's admin page. Since we have two UIs in trunk, the new and old, there are
> actually two UIs where this occurs, and the old UI has two related files that
> need updating, in order to address this issue.
> An example URL generated by the UI today is this:
> http://localhost:8983/solr/rss/select?qt=/dataimport&command=show-config
> And here it is without using qt:
> http://localhost:8983/solr/rss/dataimport?command=show-config
> I do realize that fixing this issue as I do in my patch will make the UI not
> work if the DIH isn't registered with a leading '/', but honestly I wonder
> who if anyone out there does that. And even then, it's easily rectified.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-3096) Add book information to the new website
[ https://issues.apache.org/jira/browse/SOLR-3096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley closed SOLR-3096. -- > Add book information to the new website > --- > > Key: SOLR-3096 > URL: https://issues.apache.org/jira/browse/SOLR-3096 > Project: Solr > Issue Type: Task >Reporter: David Smiley >Assignee: David Smiley > Attachments: website_books.patch > > > The attached patch modifies the new website design to incorporate the book > information. It ads a header "mantle" slideshow entry with both book images > (just the 2 current books), and it adds a book page with the 3 books > published (this includes the 1st edition that is out of date now). The image > files referenced are the same actual binary images on the current website by > I chose a more consistent naming convention. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-2852) SolrJ doesn't need woodstox jar
[ https://issues.apache.org/jira/browse/SOLR-2852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley closed SOLR-2852. -- Resolution: Won't Fix After some deliberations I had on IRC #lucene-dev with Steve Rowe and Chris Male, I haven't convinced them and so I will close the issue. > SolrJ doesn't need woodstox jar > --- > > Key: SOLR-2852 > URL: https://issues.apache.org/jira/browse/SOLR-2852 > Project: Solr > Issue Type: Improvement > Components: clients - java >Reporter: David Smiley >Priority: Trivial > > The /dist/solrj-lib/ directory contains wstx-asl-3.2.7.jar (Woodstox StAX > API). SolrJ doesn't actually have any type of dependency on this library. > The maven build doesn't have it as a dependency and the tests pass. Perhaps > Woodstox is faster than the JDK's StAX, I don't know, but I find that point > quite moot since SolrJ can use the efficient binary format. Woodstox is not > a small library either, weighting in at 524KB, and of course if someone > actually wants to use it, they can. > I propose woodstox be removed as a SolrJ dependency. I am *not* proposing it > be removed as a Solr WAR dependency since it is actually required there due > to an obscure XSLT issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
