[jira] [Commented] (SOLR-13593) Allow to look-up analyzer components by their SPI names in field type configuration
[
https://issues.apache.org/jira/browse/SOLR-13593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16918841#comment-16918841
]
Alexandre Rafalovitch commented on SOLR-13593:
--
Do we have a list of all those *names* somewhere, accessible to a non-developer?
How would a user find additional documentation on properties for those names.
Or if they wanted to compose their own chain?
Previously, they searched/checked Javadoc by the class name. What would they do
now?
> Allow to look-up analyzer components by their SPI names in field type
> configuration
> ---
>
> Key: SOLR-13593
> URL: https://issues.apache.org/jira/browse/SOLR-13593
> Project: Solr
> Issue Type: Improvement
> Components: Schema and Analysis
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: SOLR-13593-add-spi-ReversedWildcardFilterFactory.patch,
> SOLR-13593.patch
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Now each analysis factory has explicitely documented SPI name which is stored
> in the static "NAME" field (LUCENE-8778).
> Solr uses factories' simple class name in schema definition (like
> class="solr.WhitespaceTokenizerFactory"), but we should be able to also use
> more concise SPI names (like name="whitespace").
> e.g.:
> {code:xml}
>
>
>
> />
>
>
>
> {code}
> would be
> {code:xml}
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-9894) Tokenizer work randomly
[ https://issues.apache.org/jira/browse/SOLR-9894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandre Rafalovitch closed SOLR-9894. --- > Tokenizer work randomly > --- > > Key: SOLR-9894 > URL: https://issues.apache.org/jira/browse/SOLR-9894 > Project: Solr > Issue Type: Bug > Components: query parsers >Affects Versions: 6.2.1 > Environment: solrcloud 6.2.1(3 solr nodes) > OS:linux > RAM:8G >Reporter: 王海涛 >Priority: Critical > Labels: patch > Attachments: step1.png, step2.png, step3.png, step4.png > > > my schema.xml has a fieldType as folow: > > >class="org.wltea.analyzer.lucene.IKTokenizerFactory" useSmart="false"/> >class="org.wltea.pinyin.solr5.PinyinTokenFilterFactory" pinyinAll="true" > minTermLength="2"/> > > > >class="org.wltea.analyzer.lucene.IKTokenizerFactory" useSmart="true"/> > > > > Attention: > index tokenzier useSmart is false > query tokenzier useSmart is true > But when I send query request with parameter q , > the query tokenziner sometimes useSmart equals true > sometimes useSmart equal false. > That is so terrible! > I guess the problem may be caught by tokenizer cache. > when I query ,the tokenizer should use true as the useSmart's value, > but it had cache the wrong tokenizer result which created by indexWriter who > use false as useSmart's value. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13652) Remove update from initParams in example solrconfig files that only mention "df"
[ https://issues.apache.org/jira/browse/SOLR-13652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16892870#comment-16892870 ] Alexandre Rafalovitch commented on SOLR-13652: -- There is two reference to update there. One just update and one wildcard. The proposal is to remove both? I wonder if the wildcard option hits some sort of use-case that we may not remember about. > Remove update from initParams in example solrconfig files that only mention > "df" > > > Key: SOLR-13652 > URL: https://issues.apache.org/jira/browse/SOLR-13652 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Priority: Minor > Labels: easyfix, newbie > > At least some of the solrconfig files we ship have this entry: > path="/update/**,/query,/select,/tvrh,/elevate,/spell,/browse,update"> > > text > > > > which has lead at least one user to wonder if there's some kind of automatic > way to have the df field populated for updates. I don't even know how you'd > send an update that didn't have a specific field. We should remove the > "update/**". -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8883) CHANGES.txt: Auto add issue categories on new releases
[ https://issues.apache.org/jira/browse/LUCENE-8883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16881276#comment-16881276 ] Alexandre Rafalovitch commented on LUCENE-8883: --- [~dsmiley] I was more referring to the fact that the change entries have several possible formats, but they are kind of implicit. It could be nice to have those explicit, so people copy/past/fill-in blanks. But I realize that this may be better belonging to the internal documentation that we will have once the Wiki is migration to the new Guide infrastructure. > CHANGES.txt: Auto add issue categories on new releases > -- > > Key: LUCENE-8883 > URL: https://issues.apache.org/jira/browse/LUCENE-8883 > Project: Lucene - Core > Issue Type: Task > Components: general/build >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Attachments: LUCENE-8883.patch > > > As I write this, looking at Solr's CHANGES.txt for 8.2 I see we have some > sections: "Upgrade Notes", "New Features", "Bug Fixes", and "Other Changes". > There is no "Improvements" so no surprise here, the New Features category > has issues that ought to be listed as such. I think the order vary as well. > I propose that on new releases, the initial state of the next release in > CHANGES.txt have these sections. They can easily be removed at the upcoming > release if there are no such sections, or they could stay as empty. It seems > addVersion.py is the code that sets this up and it could be enhanced. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13571) Make recent RefGuide rank well in Google
[
https://issues.apache.org/jira/browse/SOLR-13571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16874944#comment-16874944
]
Alexandre Rafalovitch commented on SOLR-13571:
--
We could definitely do a sitemap.
But also, we could update the redirect list and see if that makes a lot of
difference. I had a quick look in the infra repo and it seems to be two files:
(solr_id_to_new.map.txt and solr_name_to_new.map.txt). This seems to correspond
to those we generated in SOLR-10595. So perhaps we just need to review those
files for target file name changes (may be 99% same) and ask Infra to refresh
files with new URL base of 8.1.
Also, if we could get access to the Google Webmaster tools, that would be nice.
It can be done by publishing a file to the server, can we do that outside of a
full publication process.
Finally, if we republish 6.6 with additional canonical header pointing to
latest (or 8.1 or whatever), this may also refocus the search ranking. The work
for that would probably be identical to that required to redo the maps.
> Make recent RefGuide rank well in Google
>
>
> Key: SOLR-13571
> URL: https://issues.apache.org/jira/browse/SOLR-13571
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Reporter: Jan Høydahl
>Priority: Major
>
> Spinoff from SOLR-13548
> The old Confluence ref-guide has a lot of pages pointing to it, and all of
> that link karma is delegated to the {{/solr/guide/6_6/}} html ref guide,
> making it often rank top. However we'd want newer content to rank high. See
> these comments for some first ideas.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13571) Make recent RefGuide rank well in Google
[
https://issues.apache.org/jira/browse/SOLR-13571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16874253#comment-16874253
]
Alexandre Rafalovitch commented on SOLR-13571:
--
I guess, one place to start thinking this through is on how important it is
that users find the reference manual. As a reference, Stack Overflow (and rest
of the network) have more focus on being discovered by Google than on their
internal engines. Obviously, they have too, as that's where money and attention
is. But it is still an interesting explicit goal post.
For us, if the users cannot find a relevant reference guide page quickly, they
may
* think a particular feature does not exist
* join and ask on the User Mailing list
* discover the reference guide in general and browse through it
* discover the reference guide and use our - still limited - internal search
None of the options above seem optimal compared to leveraging the public search
engine. But then, we have to worry about SEO. Clearly, the current SEO works
well enough to get us to the 6.6 version of the guide and - very importantly -
to a somewhat relevant page. Switching that to be a single target page would be
easier for us, but may cost a lot of SEO. And, frankly, I am not at all sure
that our guide is SEO-friendly enough on its own. I just did a search for
MappingCharFilterFactory (as an example) and 6.6 RefGuide is at the top
followed by (old) Javadoc, (old) Wiki, two source-code class links and then
random websites and blogs. Latest version link just does not seem to appear in
the first couple of pages (though 7.x clone of the RefGuide on some Chinese
community site does).
I suspect that Google is detecting multiple guide versions as duplicate content
and therefore only displays one version and the 6.6 version has more weight due
to redirects. But if we remove/collapse that link, I am not sure if the
correct/latest version of the manual will be picked up. This feels risky to me.
I don't know what the optimal solution is, given the limited resources
available for this part of the project. I am just really worried that lost
Google ranking is hard to get back. Perhaps, as a minimum step, we could just
refresh the URL map periodically to use whatever latest version is.
> Make recent RefGuide rank well in Google
>
>
> Key: SOLR-13571
> URL: https://issues.apache.org/jira/browse/SOLR-13571
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Reporter: Jan Høydahl
>Priority: Major
>
> Spinoff from SOLR-13548
> The old Confluence ref-guide has a lot of pages pointing to it, and all of
> that link karma is delegated to the {{/solr/guide/6_6/}} html ref guide,
> making it often rank top. However we'd want newer content to rank high. See
> these comments for some first ideas.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8883) CHANGES.txt: Auto add issue categories on new releases
[ https://issues.apache.org/jira/browse/LUCENE-8883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16873367#comment-16873367 ] Alexandre Rafalovitch commented on LUCENE-8883: --- I wonder if we could also include the templates for various ways to make the actual change entry (single JIRA, multi JIRA, multi-users, hattip, username vs real names, etc). The ideal thing would have been to be able to completely parse the README entries, instead of regexp hack them as happens now for HTML conversion. > CHANGES.txt: Auto add issue categories on new releases > -- > > Key: LUCENE-8883 > URL: https://issues.apache.org/jira/browse/LUCENE-8883 > Project: Lucene - Core > Issue Type: Task > Components: general/build >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > > As I write this, looking at Solr's CHANGES.txt for 8.2 I see we have some > sections: "Upgrade Notes", "New Features", "Bug Fixes", and "Other Changes". > There is no "Improvements" so no surprise here, the New Features category > has issues that ought to be listed as such. I think the order vary as well. > I propose that on new releases, the initial state of the next release in > CHANGES.txt have these sections. They can easily be removed at the upcoming > release if there are no such sections, or they could stay as empty. It seems > addVersion.py is the code that sets this up and it could be enhanced. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13548) Migrate Solr's Moin wiki to Confluence
[
https://issues.apache.org/jira/browse/SOLR-13548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16868563#comment-16868563
]
Alexandre Rafalovitch commented on SOLR-13548:
--
I think discarding Google juice would be very hurtful. My suggestion would be
instead to update the redirects to the whatever the latest guide is. This may
(or may not) involve having to compare the redirect map to the current 8.x
pages list.
The alternative/additive option could be to regenerate all the previous guide
versions and add [canonical
link|https://en.wikipedia.org/wiki/Canonical_link_element] to the latest one
(where they match).
And yes, the "latest" url could be nice. May even help with the canonical
references by providing stable end-point.
> Migrate Solr's Moin wiki to Confluence
> --
>
> Key: SOLR-13548
> URL: https://issues.apache.org/jira/browse/SOLR-13548
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: website
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Attachments: SolrCwikiPages.txt, SolrMoinTitles.txt,
> create_dummy_confluence_pages.py
>
>
> We have a deadline end of June to migrate Moin wiki to Confluence.
> This Jira will track migration of Solr's [https://wiki.apache.org/solr/] over
> to [https://cwiki.apache.org/confluence/display/SOLR]
> The old Confluence space currently hosts the old Reference Guide for version
> 6.5 before we moved to asciidoc. This will be overwritten.
> Steps:
> # Delete all pages in current SOLR space
> ## Q: Can we do a bulk delete ourselves or do we need to ask INFRA?
> # The rules in {{.htaccess}} which redirects to the 6.6 guide will remain as
> is
> # Run the migration tool at
> [https://selfserve.apache.org|https://selfserve.apache.org/]
> # Add a clearly visible link from front page to the ref guide for people
> landing there for docs
> After migration we'll clean up and weed out what is not needed, and then
> start moving developer-centric content into the main git repo (which will be
> covered in other JIRAs)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13548) Migrate Solr's Moin wiki to Confluence
[
https://issues.apache.org/jira/browse/SOLR-13548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16868446#comment-16868446
]
Alexandre Rafalovitch commented on SOLR-13548:
--
For the SolrMoin titles, if we could get a similar listing of another project,
all the shared names are probably the system ones. May be an easy way to cull
at least 30% of them...
I can also confirm that all 7 Russian pages are just System information (Help
mostly).
> Migrate Solr's Moin wiki to Confluence
> --
>
> Key: SOLR-13548
> URL: https://issues.apache.org/jira/browse/SOLR-13548
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: website
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Attachments: SolrCwikiPages.txt, SolrMoinTitles.txt,
> create_dummy_confluence_pages.py
>
>
> We have a deadline end of June to migrate Moin wiki to Confluence.
> This Jira will track migration of Solr's [https://wiki.apache.org/solr/] over
> to [https://cwiki.apache.org/confluence/display/SOLR]
> The old Confluence space currently hosts the old Reference Guide for version
> 6.5 before we moved to asciidoc. This will be overwritten.
> Steps:
> # Delete all pages in current SOLR space
> ## Q: Can we do a bulk delete ourselves or do we need to ask INFRA?
> # The rules in {{.htaccess}} which redirects to the 6.6 guide will remain as
> is
> # Run the migration tool at
> [https://selfserve.apache.org|https://selfserve.apache.org/]
> # Add a clearly visible link from front page to the ref guide for people
> landing there for docs
> After migration we'll clean up and weed out what is not needed, and then
> start moving developer-centric content into the main git repo (which will be
> covered in other JIRAs)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13548) Migrate Solr's Moin wiki to Confluence
[
https://issues.apache.org/jira/browse/SOLR-13548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16868444#comment-16868444
]
Alexandre Rafalovitch commented on SOLR-13548:
--
A related but tangential comment. Our strongest Google Reference guide all show
version 6.6. I never understood why, but I guess the confluence redirects are
that reason. I am not sure if removing those redirects will help surface latest
content or will bury Solr Reference guide even further.
> Migrate Solr's Moin wiki to Confluence
> --
>
> Key: SOLR-13548
> URL: https://issues.apache.org/jira/browse/SOLR-13548
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: website
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Attachments: SolrCwikiPages.txt, SolrMoinTitles.txt,
> create_dummy_confluence_pages.py
>
>
> We have a deadline end of June to migrate Moin wiki to Confluence.
> This Jira will track migration of Solr's [https://wiki.apache.org/solr/] over
> to [https://cwiki.apache.org/confluence/display/SOLR]
> The old Confluence space currently hosts the old Reference Guide for version
> 6.5 before we moved to asciidoc. This will be overwritten.
> Steps:
> # Delete all pages in current SOLR space
> ## Q: Can we do a bulk delete ourselves or do we need to ask INFRA?
> # The rules in {{.htaccess}} which redirects to the 6.6 guide will remain as
> is
> # Run the migration tool at
> [https://selfserve.apache.org|https://selfserve.apache.org/]
> # Add a clearly visible link from front page to the ref guide for people
> landing there for docs
> After migration we'll clean up and weed out what is not needed, and then
> start moving developer-centric content into the main git repo (which will be
> covered in other JIRAs)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-13540) Is it possible configure a single data-config.xml file for all the environments?
[ https://issues.apache.org/jira/browse/SOLR-13540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandre Rafalovitch resolved SOLR-13540. -- Resolution: Invalid This is not a correct usage of issue tracker for Solr project. We use it to track bugs and issues. The correct location for this question is Solr Users mailing list. Especially because what you are asking is possible in several different ways and worth a discussion. In short points: * DIH is no longer recommended for the production environments (never really was) * You can pass environmental variables into most of Solr and you can define those IIRC on command line, in solrconfig.xml or in core.properties * You may also be able to use JDBC pools and use Java standard ways to separate environments for that (this may or may not work with recent Solr versions, due to bundling of Jetty) > Is it possible configure a single data-config.xml file for all the > environments? > > > Key: SOLR-13540 > URL: https://issues.apache.org/jira/browse/SOLR-13540 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 5.5.5 >Reporter: Hugo Rodriguez >Priority: Major > > Hi > I need to configure a single data-config.xml file in solr for SAS AML 7.1. I > have three environments: Development, quality and production, and you know > the first lines in a data-config.xml file is for connection to a database > (database name, database server, port, user, password, etc). According to > this, is it possible to configure only one file (data.config.xml) that > dinamically connects for each of the databases in all environments? > Thanks for all your answers > Best regards > Hugo Rodriguez R -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-13540) Is it possible configure a single data-config.xml file for all the environments?
[ https://issues.apache.org/jira/browse/SOLR-13540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandre Rafalovitch closed SOLR-13540. > Is it possible configure a single data-config.xml file for all the > environments? > > > Key: SOLR-13540 > URL: https://issues.apache.org/jira/browse/SOLR-13540 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 5.5.5 >Reporter: Hugo Rodriguez >Priority: Major > > Hi > I need to configure a single data-config.xml file in solr for SAS AML 7.1. I > have three environments: Development, quality and production, and you know > the first lines in a data-config.xml file is for connection to a database > (database name, database server, port, user, password, etc). According to > this, is it possible to configure only one file (data.config.xml) that > dinamically connects for each of the databases in all environments? > Thanks for all your answers > Best regards > Hugo Rodriguez R -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13534) Dynamic loading of jars from a url
[
https://issues.apache.org/jira/browse/SOLR-13534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861574#comment-16861574
]
Alexandre Rafalovitch commented on SOLR-13534:
--
Well, all the security worries are based on somehow the URL being injecting
into the system. So, the URL could point at a non-jar file that will trigger
some negative reaction (escalation, crash, denial of service, etc). E.g. if the
target file is a 200Gb video...
> Dynamic loading of jars from a url
> --
>
> Key: SOLR-13534
> URL: https://issues.apache.org/jira/browse/SOLR-13534
> Project: Solr
> Issue Type: Improvement
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Dynamic loading is possible from {{.system}} collection. It's much easier to
> host the jars on a remote service and load it from there. This way the user
> should have no problem in loading jars when the {{.system}} collection is not
> available for some reason.
> The steps should look as follows
> # get the hash of your jar file. {{openssl dgst -sha512 }}
> # upload it your hosting service . say the location is
> {{[http://host:port/my-jar/location|http://hostport/]}}
> # create a runtime lib entry for the collection as follows
> {code:java}
> curl http://localhost:8983/solr/techproducts/config -H
> 'Content-type:application/json' -d '{
>"add-runtimelib": { "name":"jarblobname",
> "sha512":"e94bb3990b39aacdabaa3eef7ca6102d96fa46766048da50269f25fd41164440a4e024d7a7fb0d5ec328cd8322bb65f5ba7886e076a8f224f78cb310fd45896d"
> , "url" : "http://host:port/my-jar/loaction"}
> }'
> {code}
> to update the jar, just repeat the steps and use the {{update-runtimelib}} to
> update the sha512 hash
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13534) Dynamic loading of jars from a url
[
https://issues.apache.org/jira/browse/SOLR-13534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861563#comment-16861563
]
Alexandre Rafalovitch commented on SOLR-13534:
--
I feel sha512 is good for verification, but it still opens up an attack vector
of whatever downloads the archive before the actual verification step.
Also, perhaps there should be a INFO log message or similar if this is enabled.
And I am guessing if the local copies of the jar are missing, it (they) will
all be loaded from the remote location on startup. Is there an issue with
multiple entries hitting the same URL?
> Dynamic loading of jars from a url
> --
>
> Key: SOLR-13534
> URL: https://issues.apache.org/jira/browse/SOLR-13534
> Project: Solr
> Issue Type: Improvement
>Reporter: Noble Paul
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Dynamic loading is possible from {{.system}} collection. It's much easier to
> host the jars on a remote service and load it from there. This way the user
> should have no problem in loading jars when the {{.system}} collection is not
> available for some reason.
> The steps should look as follows
> # get the hash of your jar file. {{openssl dgst -sha512 }}
> # upload it your hosting service . say the location is
> {{[http://host:port/my-jar/location|http://hostport/]}}
> # create a runtime lib entry for the collection as follows
> {code:java}
> curl http://localhost:8983/solr/techproducts/config -H
> 'Content-type:application/json' -d '{
>"add-runtimelib": { "name":"jarblobname",
> "sha512":"e94bb3990b39aacdabaa3eef7ca6102d96fa46766048da50269f25fd41164440a4e024d7a7fb0d5ec328cd8322bb65f5ba7886e076a8f224f78cb310fd45896d"
> , "url" : "http://host:port/my-jar/loaction"}
> }'
> {code}
> to update the jar, just repeat the steps and use the {{update-runtimelib}} to
> update the sha512 hash
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13266) /update/json/docs should support the JSON record format
[ https://issues.apache.org/jira/browse/SOLR-13266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861378#comment-16861378 ] Alexandre Rafalovitch commented on SOLR-13266: -- We support [JSONLines|http://jsonlines.org/], what exactly is the difference? > /update/json/docs should support the JSON record format > --- > > Key: SOLR-13266 > URL: https://issues.apache.org/jira/browse/SOLR-13266 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Priority: Major > > This is a standard [JSON format |https://tools.ietf.org/html/rfc7464]that > Solr does not support -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11724) Cdcr Bootstrapping does not cause "index copying" to follower nodes on Target
[ https://issues.apache.org/jira/browse/SOLR-11724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16858464#comment-16858464 ] Alexandre Rafalovitch commented on SOLR-11724: -- This issue is marked as part of 7.3.1, but was it actually? It is the only issue as marked unfinished against the completed 7.3.1 release. > Cdcr Bootstrapping does not cause "index copying" to follower nodes on Target > - > > Key: SOLR-11724 > URL: https://issues.apache.org/jira/browse/SOLR-11724 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: CDCR >Reporter: Amrit Sarkar >Assignee: Varun Thacker >Priority: Major > Fix For: 7.3.1, 7.4, 8.0 > > Attachments: SOLR-11724.patch, SOLR-11724.patch, SOLR-11724.patch, > SOLR-11724.patch > > > Please find the discussion on: > http://lucene.472066.n3.nabble.com/Issue-with-CDCR-bootstrapping-in-Solr-7-1-td4365258.html > If we index significant documents in to Source, stop indexing and then start > CDCR; bootstrapping only copies the index to leader node of shards of the > collection, and followers never receive the documents / index until and > unless atleast one document is inserted again on source; which propels to > target and target collection trigger index replication to followers. > This behavior needs to be addressed in proper manner, either at target > collection or while bootstrapping. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10329) Rebuild Solr examples
[ https://issues.apache.org/jira/browse/SOLR-10329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16801563#comment-16801563 ] Alexandre Rafalovitch commented on SOLR-10329: -- The JIRA itself is still open, anybody can work on it. Any member of community will see the proposed patches and will be able to comment on them. Specifically, for GSoC, I am not mentoring this year, so this is probably not the best JIRA to jump on for that purpose. > Rebuild Solr examples > - > > Key: SOLR-10329 > URL: https://issues.apache.org/jira/browse/SOLR-10329 > Project: Solr > Issue Type: Wish > Components: examples >Reporter: Alexandre Rafalovitch >Priority: Major > Labels: gsoc2017 > > Apache Solr ships with a number of examples. They evolved from a kitchen sync > example and are rather large. When new Solr features are added, they are > often shoehorned into the most appropriate example and sometimes are not > represented at all. > Often, for new users, it is hard to tell what part of example is relevant, > what part is default and what part is demonstrating something completely > different. > It would take significant (and very appreciated) effort to review all the > examples and rebuild them to provide clean way to showcase best practices > around base and most recent features. > Specific issues are around kitchen sync vs. minimal examples, better approach > to "schemaless" mode and creating examples and datasets that allow to create > both "hello world" and more-advanced tutorials. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-11393) Unable to index field names in JSON
[
https://issues.apache.org/jira/browse/SOLR-11393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandre Rafalovitch closed SOLR-11393.
> Unable to index field names in JSON
> ---
>
> Key: SOLR-11393
> URL: https://issues.apache.org/jira/browse/SOLR-11393
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Affects Versions: 6.6.1
>Reporter: Cheburakshu
>Priority: Major
>
> I am not able to index documents with below field names in JSON doc.
> config_os_version
> location_region
> custom_var_v2
> deleted
> I get the below error
> ERROR: [doc=29128e37-c6d9-4d2b-814e-1d42f84be9b5] Error adding field
> 'location_region'='test' msg=For input string: "test"
> The input given in admin UI /update endpoint is
> {"location_region":"test"}
> Same error was encountered for other field names as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-5283) Admin UI issues in IE7
[
https://issues.apache.org/jira/browse/SOLR-5283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandre Rafalovitch closed SOLR-5283.
---
> Admin UI issues in IE7
> --
>
> Key: SOLR-5283
> URL: https://issues.apache.org/jira/browse/SOLR-5283
> Project: Solr
> Issue Type: Bug
> Components: Admin UI
>Affects Versions: 4.4
> Environment: IE Version 7.0.5730.11 64-bit edition.
>Reporter: Erik Hatcher
>Priority: Minor
>
> A customer of ours reported:
> {code}
> IE Version 7.0.5730.11 64-bit edition.
> Result:
> Left nav area displays;
> Main area: spinning loading icon displaying the word Loading ...
> Script errors on page:
> Line: 8
> Char: 3
> Error: 'CSSStyleDeclaration' is undefined
> Code: 0
> URL: http://:/solr/js/lib/d3.js
> Line: 17
> Char: 5
> Error: Unexpected call to method or property access.
> Code: 0
> URL : http://:/solr/js/require.js
> {code}
> I've tried replicating this in a Windows virtual machine, but only have IE10
> and have not seen this issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-7858) Make Angular UI default
[ https://issues.apache.org/jira/browse/SOLR-7858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandre Rafalovitch closed SOLR-7858. --- > Make Angular UI default > --- > > Key: SOLR-7858 > URL: https://issues.apache.org/jira/browse/SOLR-7858 > Project: Solr > Issue Type: Bug > Components: Admin UI >Reporter: Upayavira >Assignee: Upayavira >Priority: Minor > Fix For: 6.0 > > Attachments: SOLR-7858-2.patch, SOLR-7858-3.patch, SOLR-7858-4.patch, > SOLR-7858-fix.patch, SOLR-7858.patch, new ui link.png, original UI link.png > > > Angular UI is very close to feature complete. Once SOLR-7856 is dealt with, > it should function well in most cases. I propose that, as soon as 5.3 has > been released, we make the Angular UI default, ready for the 5.4 release. We > can then fix any more bugs as they are found, but more importantly start > working on the features that were the reason for doing this work in the first > place. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-13018) In solr-cloud mode, It throws an error when i create a collection with schema that has fieldType containing openNLP tokenizer and filters
[
https://issues.apache.org/jira/browse/SOLR-13018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandre Rafalovitch closed SOLR-13018.
> In solr-cloud mode, It throws an error when i create a collection with schema
> that has fieldType containing openNLP tokenizer and filters
> -
>
> Key: SOLR-13018
> URL: https://issues.apache.org/jira/browse/SOLR-13018
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI, SolrCloud
>Affects Versions: 7.3.1
>Reporter: Parmeshwor Thapa
>Priority: Major
>
> Here is schema for field:
> {code:java}
>
>
> tokenizerModel="en-token.bin" sentenceModel="en-sent.bin"/>
>
> posTaggerModel="en-pos-maxent.bin"/>
> dictionary="en-lemmatizer.txt"/>
>
>
>
>
>
> {code}
> I have configset with all the files(en-token.bin, en-sent.bin, ...) in same
> directory. Using that configset i can successfully create Solr Core in
> Standalone mode.
> But With Solr cloud (two instances in separate servers orchestrated by
> zookeeper) i have the same configset in both servers and i try to create a
> collection, it is throwing me an error which doesn't make any sense to me.
> {code:java}
> $ bin/solr create -p 8984 -c xyz -n xyz_conf -d xyz_conf
> ... ERROR: Failed to create collection 'xyz' due to:
> {example1.com:8984_solr=org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error
> from server at https://example2.com:8984/solr: Error CREATEing SolrCore
> 'xyz_shard1_replica_n1': Unable to create core [xyz_shard1_replica_n1] Caused
> by: Can't find resource 'solrconfig.xml' in classpath or '/configs/xyz',
> cwd=/opt/solr-7.3.1/server}
> {code}
>
>
> Note: uploading configset to zookeeper also fails with error
> {code:java}
> $ bin/solr create -c xyz -n xyz_conf -d xyz_conf
> ...
> —
> ERROR: Error uploading file
> /opt/solr/server/solr/configsets/xyz/conf/en-pos-maxent.bin to zookeeper path
> /configs/xyz/en-pos-maxent.bin
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-12600) Parameters mapping for query parameters to JSON query
[ https://issues.apache.org/jira/browse/SOLR-12600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandre Rafalovitch closed SOLR-12600. > Parameters mapping for query parameters to JSON query > - > > Key: SOLR-12600 > URL: https://issues.apache.org/jira/browse/SOLR-12600 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Affects Versions: 7.4 >Reporter: Renuka Srishti >Assignee: Alexandre Rafalovitch >Priority: Minor > Fix For: 7.6 > > > Paramters mapping mentioned here is not right. > start, rows works for standard query parameters. > offset, limit works for JSON query. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-12956) Add @since javadoc tags to the Analyzer component classes
[ https://issues.apache.org/jira/browse/SOLR-12956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandre Rafalovitch closed SOLR-12956. > Add @since javadoc tags to the Analyzer component classes > - > > Key: SOLR-12956 > URL: https://issues.apache.org/jira/browse/SOLR-12956 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Affects Versions: 7.5 >Reporter: Alexandre Rafalovitch >Assignee: Alexandre Rafalovitch >Priority: Minor > Fix For: 7.6 > > Attachments: SOLR-12956.patch > > > Continuing work started in SOLR-11490, add @since javadoc tags to all > Analyzer, Tokenizer, Char and Token filter classes that are used in the > fieldtype definitions. > As per the previous guidance, earliest version tag applied will be 3.1. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-2767) ClassCastException when using FieldAnalysisResponse and the analyzer list contains the CharMappingFilter (or any CharFilter)
[ https://issues.apache.org/jira/browse/SOLR-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandre Rafalovitch resolved SOLR-2767. - Resolution: Duplicate Should be resolved by SOLR-2834. Please open a new case if the issue still persists, as the underlying code has changed a lot since. > ClassCastException when using FieldAnalysisResponse and the analyzer list > contains the CharMappingFilter (or any CharFilter) > > > Key: SOLR-2767 > URL: https://issues.apache.org/jira/browse/SOLR-2767 > Project: Solr > Issue Type: Bug >Affects Versions: 3.3, 4.0-ALPHA >Reporter: Spyros Kapnissis >Priority: Major > Attachments: SOLR-2767.patch > > > I use the FieldAnalysisResponse class in order to gather some information > about the analysis process. However, I get a ClassCastException (cannot > convert String to NamedList) thrown at > AnalysisResponseBase.buildPhases method if I have included the > CharMappingFilter in my configuration. > It seems that a CharFilter does not create a NamedList, but a String > entry in the analysis response. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-8177) About AnalysisResponseBase => java.lang.String cannot be cast to java.util.List
[ https://issues.apache.org/jira/browse/SOLR-8177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandre Rafalovitch resolved SOLR-8177. - Resolution: Duplicate Should be resolved by SOLR-2834. Please open a new case if the issue still persists, as the underlying code has changed a lot since. > About AnalysisResponseBase => java.lang.String cannot be cast to > java.util.List > > > Key: SOLR-8177 > URL: https://issues.apache.org/jira/browse/SOLR-8177 > Project: Solr > Issue Type: Bug > Components: clients - java >Affects Versions: 5.1 > Environment: centos6.5 > jdk1.7 >Reporter: kim >Priority: Major > Labels: easyfix > Original Estimate: 5h > Remaining Estimate: 5h > > In FieldType , eg text , if i add a charFilter then , use > FieldAnalysisRequest > build analysis phases list will lead a java.lang.String cannot be cast to > java.util.List , i have seen the source code ， it seems don't to solve if > have a charFilter situation , > AnyOne know why this is , please reply me ! -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-8237) Invalid parsing with solr edismax operators
[ https://issues.apache.org/jira/browse/SOLR-8237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandre Rafalovitch resolved SOLR-8237. - Resolution: Implemented > Invalid parsing with solr edismax operators > --- > > Key: SOLR-8237 > URL: https://issues.apache.org/jira/browse/SOLR-8237 > Project: Solr > Issue Type: Bug > Components: query parsers >Affects Versions: 4.8.1 > Environment: Windows 2008 R2 - Apache TomCat 7 >Reporter: Mahmoud Almokadem >Priority: Critical > Labels: edismax > > Using edismax as the parser we got the undesirable parsed queries and > results. The following is two different cases with strange behavior: > Searching with these parameters > "mm":"2", > "df":"TotalField", > "debug":"true", > "indent":"true", > "fl":"Title", > "start":"0", > "q.op":"AND", > "fq":"", > "rows":"10", > "wt":"json" > and the query is > "q":"+(public libraries)", > Retrieve 502 documents with these parsed query > "rawquerystring":"+(public libraries)", > "querystring":"+(public libraries)", > "parsedquery":"(+(+(DisjunctionMaxQuery((Title:public^200.0 | > TotalField:public^0.1)) DisjunctionMaxQuery((Title:libraries^200.0 | > TotalField:libraries^0.1)/no_coord", > "parsedquery_toString":"+(+((Title:public^200.0 | TotalField:public^0.1) > (Title:libraries^200.0 | TotalField:libraries^0.1)))" > and if the query is > "q":" (public libraries) " > then it retrieves 8 documents with these parsed query > "rawquerystring":" (public libraries) ", > "querystring":" (public libraries) ", > "parsedquery":"(+((DisjunctionMaxQuery((Title:public^200.0 | > TotalField:public^0.1)) DisjunctionMaxQuery((Title:libraries^200.0 | > TotalField:libraries^0.1)))~2))/no_coord", > "parsedquery_toString":"+(((Title:public^200.0 | TotalField:public^0.1) > (Title:libraries^200.0 | TotalField:libraries^0.1))~2)" > So the results of adding "+" to get all tokens before the parenthesis > retrieve more results than removing it. > Request Handler > > explicit > 10 > TotalField > AND > edismax > Title^200 TotalField^1 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12996) ShingleFilterFactory fillerToken parameter is not in Reference Guide
Alexandre Rafalovitch created SOLR-12996: Summary: ShingleFilterFactory fillerToken parameter is not in Reference Guide Key: SOLR-12996 URL: https://issues.apache.org/jira/browse/SOLR-12996 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: documentation Affects Versions: 7.5 Reporter: Alexandre Rafalovitch Assignee: Alexandre Rafalovitch An issue came up on the mailing list regarding shingle configuration. And we noticed that fillerToken parameter is in Javadocs (and source) but not in the Reference Guide. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-12600) Parameters mapping for query parameters to JSON query
[ https://issues.apache.org/jira/browse/SOLR-12600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandre Rafalovitch resolved SOLR-12600. -- Resolution: Fixed Fix Version/s: 7.6 Swapped the parameter names to actually map implementation. Also document fields->fl mapping that was missing. > Parameters mapping for query parameters to JSON query > - > > Key: SOLR-12600 > URL: https://issues.apache.org/jira/browse/SOLR-12600 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Affects Versions: 7.4 >Reporter: Renuka Srishti >Assignee: Alexandre Rafalovitch >Priority: Minor > Fix For: 7.6 > > > Paramters mapping mentioned here is not right. > start, rows works for standard query parameters. > offset, limit works for JSON query. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-12966) Add @since javadoc tags to the URP classes
[ https://issues.apache.org/jira/browse/SOLR-12966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandre Rafalovitch resolved SOLR-12966. -- Resolution: Implemented Fix Version/s: 7.6 > Add @since javadoc tags to the URP classes > -- > > Key: SOLR-12966 > URL: https://issues.apache.org/jira/browse/SOLR-12966 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Affects Versions: 7.5 >Reporter: Alexandre Rafalovitch >Priority: Minor > Fix For: 7.6 > > > Continuing work started in SOLR-11490, add @since javadoc tags to all > descendants of UpdateRequestProcessorFactory. > Most of them have been tagged already, just SignatureUpdateProcessorFactory > to be marked as 3.1 and new OpenNLPLangDetectUpdateProcessorFactory as 7.3.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12966) Add @since javadoc tags to the URP classes
[ https://issues.apache.org/jira/browse/SOLR-12966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandre Rafalovitch updated SOLR-12966: - Description: Continuing work started in SOLR-11490, add @since javadoc tags to all descendants of UpdateRequestProcessorFactory. Most of them have been tagged already, just SignatureUpdateProcessorFactory to be marked as 3.1 and new OpenNLPLangDetectUpdateProcessorFactory as 7.3.0 was: Continuing work started in SOLR-11490, add @since javadoc tags to all descendants of UpdateRequestProcessorFactory. Most of them have been tagged already, just SignatureUpdateProcessorFactory and UpdateRequestProcessorChain to be marked as 3.1 and new OpenNLPLangDetectUpdateProcessorFactory as 7.3.0 > Add @since javadoc tags to the URP classes > -- > > Key: SOLR-12966 > URL: https://issues.apache.org/jira/browse/SOLR-12966 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Affects Versions: 7.5 >Reporter: Alexandre Rafalovitch >Priority: Minor > > Continuing work started in SOLR-11490, add @since javadoc tags to all > descendants of UpdateRequestProcessorFactory. > Most of them have been tagged already, just SignatureUpdateProcessorFactory > to be marked as 3.1 and new OpenNLPLangDetectUpdateProcessorFactory as 7.3.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12966) Add @since javadoc tags to the URP classes
Alexandre Rafalovitch created SOLR-12966: Summary: Add @since javadoc tags to the URP classes Key: SOLR-12966 URL: https://issues.apache.org/jira/browse/SOLR-12966 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: documentation Affects Versions: 7.5 Reporter: Alexandre Rafalovitch Continuing work started in SOLR-11490, add @since javadoc tags to all descendants of UpdateRequestProcessorFactory. Most of them have been tagged already, just SignatureUpdateProcessorFactory and UpdateRequestProcessorChain to be marked as 3.1 and new OpenNLPLangDetectUpdateProcessorFactory as 7.3.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-12956) Add @since javadoc tags to the Analyzer component classes
[ https://issues.apache.org/jira/browse/SOLR-12956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandre Rafalovitch resolved SOLR-12956. -- Resolution: Implemented Fix Version/s: 7.6 > Add @since javadoc tags to the Analyzer component classes > - > > Key: SOLR-12956 > URL: https://issues.apache.org/jira/browse/SOLR-12956 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Affects Versions: 7.5 >Reporter: Alexandre Rafalovitch >Assignee: Alexandre Rafalovitch >Priority: Minor > Fix For: 7.6 > > Attachments: SOLR-12956.patch > > > Continuing work started in SOLR-11490, add @since javadoc tags to all > Analyzer, Tokenizer, Char and Token filter classes that are used in the > fieldtype definitions. > As per the previous guidance, earliest version tag applied will be 3.1. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12956) Add @since javadoc tags to the Analyzer component classes
[ https://issues.apache.org/jira/browse/SOLR-12956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandre Rafalovitch updated SOLR-12956: - Attachment: SOLR-12956.patch > Add @since javadoc tags to the Analyzer component classes > - > > Key: SOLR-12956 > URL: https://issues.apache.org/jira/browse/SOLR-12956 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Affects Versions: 7.5 >Reporter: Alexandre Rafalovitch >Assignee: Alexandre Rafalovitch >Priority: Minor > Attachments: SOLR-12956.patch > > > Continuing work started in SOLR-11490, add @since javadoc tags to all > Analyzer, Tokenizer, Char and Token filter classes that are used in the > fieldtype definitions. > As per the previous guidance, earliest version tag applied will be 3.1. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12956) Add @since javadoc tags to the Analyzer component classes
Alexandre Rafalovitch created SOLR-12956: Summary: Add @since javadoc tags to the Analyzer component classes Key: SOLR-12956 URL: https://issues.apache.org/jira/browse/SOLR-12956 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: documentation Affects Versions: 7.5 Reporter: Alexandre Rafalovitch Assignee: Alexandre Rafalovitch Continuing work started in SOLR-11490, add @since javadoc tags to all Analyzer, Tokenizer, Char and Token filter classes that are used in the fieldtype definitions. As per the previous guidance, earliest version tag applied will be 3.1. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-477) AnalysisRequestHandler
[ https://issues.apache.org/jira/browse/SOLR-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandre Rafalovitch closed SOLR-477. -- Resolved long time ago, but was not "closed". > AnalysisRequestHandler > -- > > Key: SOLR-477 > URL: https://issues.apache.org/jira/browse/SOLR-477 > Project: Solr > Issue Type: New Feature >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Attachments: SOLR-477.patch, SOLR-477.patch > > > Being able to programmatically access tokenization information can be quite > useful not only in Solr, but in other NLP applications where token vectors > are necessary. > The patch to follow creates an AnalysisRequestHandler which processes a > document through the analysis process and returns a response filled with > tokens, their offsets, position inc., type and value. > Patch also adds some character array processing to Xml and adds Token > handling to XMLWriter. > I only implemented Xml output, as I don't know JSON or the other types. If > someone else is so motivated, they can add those. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-585) ResponseBuilder.getQParser() is always null b/c it never gets set
[
https://issues.apache.org/jira/browse/SOLR-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandre Rafalovitch closed SOLR-585.
--
Resolved long time ago, but was not "closed".
> ResponseBuilder.getQParser() is always null b/c it never gets set
> -
>
> Key: SOLR-585
> URL: https://issues.apache.org/jira/browse/SOLR-585
> Project: Solr
> Issue Type: Bug
>Reporter: Grant Ingersoll
>Assignee: Grant Ingersoll
>Priority: Minor
>
> The ResponseBuilder never gets it's QParser set.
> I believe the fix is:
> {code}Index: src/java/org/apache/solr/handler/component/QueryComponent.java
> ===
> --- src/java/org/apache/solr/handler/component/QueryComponent.java
> (revision 660920)
> +++ src/java/org/apache/solr/handler/component/QueryComponent.java
> (working copy)
> @@ -80,7 +80,7 @@
>QParser parser = QParser.getParser(rb.getQueryString(), defType, req);
>rb.setQuery( parser.getQuery() );
>rb.setSortSpec( parser.getSort(true) );
> -
> + rb.setQparser(parser);
>String[] fqs =
> req.getParams().getParams(org.apache.solr.common.params.CommonParams.FQ);
>if (fqs!=null && fqs.length!=0) {
> List filters = rb.getFilters();
> {code}
> but will test it first!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-573) http cache headers should be applied ONLY to query results
[ https://issues.apache.org/jira/browse/SOLR-573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandre Rafalovitch closed SOLR-573. -- Resolved long time ago, but was not "closed". > http cache headers should be applied ONLY to query results > -- > > Key: SOLR-573 > URL: https://issues.apache.org/jira/browse/SOLR-573 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 >Reporter: David Smiley >Priority: Major > > I'm using Solr-1.3 trunk and I have http caching headers enabled. Some of my > interactions with solr using my browser (Firefox) such as using the multicore > features to reload a module were return so quick that I was suspicious that > it did anything. It turns out that it was caching the reload command and it > didn't really do anything. I think the http caching headers should only be > applied to search result queries and no other URLs for SOLR. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-255) RemoteSearchable for Solr(use RMI)
[
https://issues.apache.org/jira/browse/SOLR-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandre Rafalovitch closed SOLR-255.
--
Resolved long time ago, but was not "closed".
> RemoteSearchable for Solr(use RMI)
> --
>
> Key: SOLR-255
> URL: https://issues.apache.org/jira/browse/SOLR-255
> Project: Solr
> Issue Type: Improvement
> Components: search
>Reporter: Toru Matsuzawa
>Assignee: Otis Gospodnetic
>Priority: Major
> Attachments: solr-multi20070606.zip, solr-multi20070724..zip
>
>
> I experimentally implemented RemoteSearchable of Lucene for Solr.
> I referred to "FederatedSearch" and used RMI.
> Two or more Searchers can be referred to with SolrIndexSearcher.
> These query-only indexes can be specified in solrconfig.xml,
> enumerating the list under a tag.
>
> E:\sample\data1
> E:\sample\data2
> rmi://localhost
>
> The index in the dataDir is also used as the default index of solr
> to update and query.
> When data of a document in a index specified under the is
> updated,
> that document data in the index will be deleted and data of the updated
> document will be stored
> in the index in the dataDir.
> SolrRemoteSearchable (the searcher for remote access) is started from
> SolrCore
> by specifying "< remoteSearcher>true" in solrconfig.xml.(It
> is registered in RMI. )
> ("-Djava.security.policy" should be set when you start VM. )
> Not all of the operational cases are tested
> because Solr has so many features.
> Moreover, TestUnit has not been made
> because I made this through a trial and error process.
> Some changes are required in Lucene to execute this.
> I need your comments on this although it might be hard without TestUnit.
> I especially worry about the followings:
> - Am I on the right truck about this issue?
> - Is the extent of modifying Lucene tolerable?
> - Are there any ideas to implement this feature without modifying Lucene?
> - Does this idea contribute for improving Solr?
> - This implementation may partially overlap with "Multiple Solr Cores".
> What should be done?
> - Are there any other considerations about this issue, which I have
> overlooked?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-603) Support Partial Optimizes
[ https://issues.apache.org/jira/browse/SOLR-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandre Rafalovitch closed SOLR-603. -- Resolved long time ago, but was not "closed". > Support Partial Optimizes > - > > Key: SOLR-603 > URL: https://issues.apache.org/jira/browse/SOLR-603 > Project: Solr > Issue Type: New Feature >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Attachments: SOLR-603.patch, SOLR-603.patch > > > It would be useful if Solr supported Lucene's capability to do partial > optimizes. The associated method on the IndexWriter is > [http://lucene.apache.org/java/2_3_2/api/core/org/apache/lucene/index/IndexWriter.html#optimize(int,%20boolean)] > and the variations there-in. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-607) Commit only request handler for read only slaves
[
https://issues.apache.org/jira/browse/SOLR-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandre Rafalovitch closed SOLR-607.
--
Resolved long time, but was not "closed".
> Commit only request handler for read only slaves
>
>
> Key: SOLR-607
> URL: https://issues.apache.org/jira/browse/SOLR-607
> Project: Solr
> Issue Type: New Feature
> Components: update
>Reporter: Hoss Man
>Priority: Major
>
> Replication currently requires that the snapinstaller script be able to use
> curl to hit a URL (/update) to stream a {{{}} command to.
> To help make it easier to "secure" read only Solr slave instances, we should
> add a "CommitOnlyRequestHandler" which would ignore all content streams and
> could be used on slaves in place of XmlUpdateRequestHandler just for
> triggering a commit to open a new Searcher.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-483) short/byte sorting support
[ https://issues.apache.org/jira/browse/SOLR-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandre Rafalovitch closed SOLR-483. -- Resolved long time, but was not "closed". > short/byte sorting support > -- > > Key: SOLR-483 > URL: https://issues.apache.org/jira/browse/SOLR-483 > Project: Solr > Issue Type: Improvement >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Attachments: SOLR-483.patch > > > Similar to SOLR-324, add in sorting support for byte and shorts. Most of the > code is in the SOLR-324.patch file, just needs to have proper support from > Lucene. Lucene trunk has the capability, but it was not in the last release. > Either update to trunk at some point or wait for the next Lucene release. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12746) Ref Guide HTML output should adhere to more standard HTML5
[
https://issues.apache.org/jira/browse/SOLR-12746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16668938#comment-16668938
]
Alexandre Rafalovitch commented on SOLR-12746:
--
I can build on master yes. And it now builds on the branch with those two
dependencies commented out.
And the HTML looks so much cleaner now! And smaller.
There are still build errors for PDF and a deprecation warning for HTML stages,
but both of these are on trunk as well, so not an issue here.
+1
> Ref Guide HTML output should adhere to more standard HTML5
> --
>
> Key: SOLR-12746
> URL: https://issues.apache.org/jira/browse/SOLR-12746
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
>Priority: Major
>
> The default HTML produced by Jekyll/Asciidoctor adds a lot of extra {{}}
> tags to the content which break up our content into very small chunks. This
> is acceptable to a casual website reader as far as it goes, but any Reader
> view in a browser or another type of content extraction system that uses a
> similar "readability" scoring algorithm is going to either miss a lot of
> content or fail to display the page entirely.
> To see what I mean, take a page like
> https://lucene.apache.org/solr/guide/7_4/language-analysis.html and enable
> Reader View in your browser (I used Firefox; Steve Rowe told me offline
> Safari would not even offer the option on the page for him). You will notice
> a lot of missing content. It's almost like someone selected sentences at
> random.
> Asciidoctor has a long-standing issue to provide a better more
> semantic-oriented HTML5 output, but it has not been resolved yet:
> https://github.com/asciidoctor/asciidoctor/issues/242
> Asciidoctor does provide a way to override the default output templates by
> providing your own in Slim, HAML, ERB or any other template language
> supported by Tilt (none of which I know yet). There are some samples
> available via the Asciidoctor project which we can borrow, but it's otherwise
> unknown as of yet what parts of the output are causing the worst of the
> problems. This issue is to explore how to fix it to improve this part of the
> HTML reading experience.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12746) Ref Guide HTML output should adhere to more standard HTML5
[
https://issues.apache.org/jira/browse/SOLR-12746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16668030#comment-16668030
]
Alexandre Rafalovitch commented on SOLR-12746:
--
I tried to get this to work (ant clean build-site) but was not able to.
First, it was missing a gem, but I was able to progress by installing
asciidoctor-html5s. Except it was refusing to install with normal command, I
had to use:
{code:java}
sudo gem install asciidoctor-html5s --pre{code}
Then it was failing with conversion error on
'field-type-definitions-and-properties.adoc' due to 'Could not find a converter
to handle transform: empty'.
{code:java}
-build-site:
[echo] Running Jekyll...
[exec] Configuration file:
/home/arafalov/Solr/solr-12746/solr/build/solr-ref-guide/content/_config.yml
[exec] Source: /home/arafalov/Solr/solr-12746/solr/build/solr-ref-guide/content
[exec] Destination: ../html-site
[exec] Incremental build: disabled. Enable with --incremental
[exec] Generating... Deprecation: The 'gems' configuration option has been
renamed to 'plugins'. Please update your config file accordingly.
[exec]
[exec] jekyll 3.5.0 | Error: Could not find a converter to handle transform:
empty
[exec] Conversion error: Jekyll::AsciiDoc::Converter encountered an error
while converting 'field-type-definitions-and-properties.adoc':
[exec] Could not find a converter to handle transform: empty
[exec] Result: 1
build-site:
[java] Exception in thread "main" java.lang.NullPointerException
[java] at CheckLinksAndAnchors.main(CheckLinksAndAnchors.java:156)
{code}
I was not able to get past that. I am on Ubuntu. My gem list (gem list |grep
"jekyll\|doctor\|slim"):
{noformat}
asciidoctor (1.5.6.2)
asciidoctor-html5s (0.1.0.beta.11)
jekyll (3.5.0)
jekyll-asciidoc (2.1.0)
jekyll-sass-converter (1.5.2)
jekyll-watch (2.1.2, 1.5.1)
slim (3.0.9)
{noformat}
> Ref Guide HTML output should adhere to more standard HTML5
> --
>
> Key: SOLR-12746
> URL: https://issues.apache.org/jira/browse/SOLR-12746
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
>Priority: Major
>
> The default HTML produced by Jekyll/Asciidoctor adds a lot of extra {{}}
> tags to the content which break up our content into very small chunks. This
> is acceptable to a casual website reader as far as it goes, but any Reader
> view in a browser or another type of content extraction system that uses a
> similar "readability" scoring algorithm is going to either miss a lot of
> content or fail to display the page entirely.
> To see what I mean, take a page like
> https://lucene.apache.org/solr/guide/7_4/language-analysis.html and enable
> Reader View in your browser (I used Firefox; Steve Rowe told me offline
> Safari would not even offer the option on the page for him). You will notice
> a lot of missing content. It's almost like someone selected sentences at
> random.
> Asciidoctor has a long-standing issue to provide a better more
> semantic-oriented HTML5 output, but it has not been resolved yet:
> https://github.com/asciidoctor/asciidoctor/issues/242
> Asciidoctor does provide a way to override the default output templates by
> providing your own in Slim, HAML, ERB or any other template language
> supported by Tilt (none of which I know yet). There are some samples
> available via the Asciidoctor project which we can borrow, but it's otherwise
> unknown as of yet what parts of the output are causing the worst of the
> problems. This issue is to explore how to fix it to improve this part of the
> HTML reading experience.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12930) Add great developer documentation for writing tests.
[ https://issues.apache.org/jira/browse/SOLR-12930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16665666#comment-16665666 ] Alexandre Rafalovitch commented on SOLR-12930: -- Actually, GitHub renders Asciidoc right in the source browse, e.g.: [https://github.com/apache/lucene-solr/blob/master/solr/solr-ref-guide/src/about-filters.adoc] It is not perfect (e.g. not resolving the imports) and does not help with built-output, but it may be ok as a public preview. There is also an option of using something like [Netlify|https://www.netlify.com/] which does support Jekyll and allows to build from a repo, but it needs to be setup/configured right. A separate project. > Add great developer documentation for writing tests. > > > Key: SOLR-12930 > URL: https://issues.apache.org/jira/browse/SOLR-12930 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Reporter: Mark Miller >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12930) Add great developer documentation for writing tests.
[ https://issues.apache.org/jira/browse/SOLR-12930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16665177#comment-16665177 ] Alexandre Rafalovitch commented on SOLR-12930: -- +1 on the idea of asciidoc, especially since it allows to embed code segments straight from source, like in SolrJ example. > Add great developer documentation for writing tests. > > > Key: SOLR-12930 > URL: https://issues.apache.org/jira/browse/SOLR-12930 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Reporter: Mark Miller >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12890) Vector Search in Solr (Umbrella Issue)
[ https://issues.apache.org/jira/browse/SOLR-12890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16658236#comment-16658236 ] Alexandre Rafalovitch commented on SOLR-12890: -- Is this different from just committed SOLR-12879? Can the work be updated to build on top of that, if something is still missing? > Vector Search in Solr (Umbrella Issue) > -- > > Key: SOLR-12890 > URL: https://issues.apache.org/jira/browse/SOLR-12890 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: mosh >Priority: Major > > We have recently come across a need to index documents containing vectors > using solr, and have even worked on a small POC. We used an URP to calculate > the LSH(we chose to use the superbit algorithm, but the code is designed in a > way the algorithm picked can be easily chagned), and stored the vector in > either sparse or dense forms, in a binary field. > Perhaps an addition of an LSH URP in conjunction with a query parser that > uses the same properties to calculate LSH(or maybe ktree, or some other > algorithm all together) should be considered as a Solr feature? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12884) Admin UI, admin/luke and *Point fields
[
https://issues.apache.org/jira/browse/SOLR-12884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656937#comment-16656937
]
Alexandre Rafalovitch commented on SOLR-12884:
--
I am also seeing similar behavior for Solr 7.5's treatment of _str fields
generated by the schemaless mode. I am not sure if the cause is related or not.
> Admin UI, admin/luke and *Point fields
> --
>
> Key: SOLR-12884
> URL: https://issues.apache.org/jira/browse/SOLR-12884
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: master (8.0)
>Reporter: Erick Erickson
>Priority: Major
>
> One of the conference attendees noted that you go to the schema browser and
> click on, say, a pint field, then click "load term info", nothing is shown.
> admin/luke similarly doesn't show much interesting, here's the response for a
> pint .vs. a tint field:
> "popularity":\{ "type":"pint", "schema":"I-SD-OF--"},
> "popularityt":{ "type":"tint", "schema":"I-S--OF--",
> "index":"-TS--", "docs":15},
>
> What, if anything, should we do in these two cases? Since the points-based
> numerics don't have terms like Trie* fields, I don't think we _can_ show much
> more so the above makes sense, it's just jarring to end users and looks like
> a bug.
> WDYT about putting in some useful information though. Say for the Admin UI
> for points-based "terms cannot be shown for points-based fields" or some such?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12865) Custom JSON parser's nested documents example does not work
Alexandre Rafalovitch created SOLR-12865:
Summary: Custom JSON parser's nested documents example does not
work
Key: SOLR-12865
URL: https://issues.apache.org/jira/browse/SOLR-12865
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 7.5
Reporter: Alexandre Rafalovitch
The only exam we have for indexing nested JSON using JSON parser does not seem
to work:
[https://lucene.apache.org/solr/guide/7_5/transforming-and-indexing-custom-json.html#indexing-nested-documents]
Attempt 1, using default schemaless mode:
# bin/solr create -c json_basic
# Example command in V1 format (with core name switched to above)
# Indexing fails with: *"msg":"[doc=null] missing required field: id"*. My
guess it is because the URPs chain do not apply to inner children records
Attempt 2, using techproducts schema configuration:
# bin/solr create -c json_tp -d sample_techproducts_configs
# Same example command with new core
# Indexing fails with: *"msg":"Raw data can be stored only if split=/"* (due
to presence of srcField in the params.json)
Attempt 3, continuing the above example, but taking out srcField configuration:
# Update params.json to remove srcField
# Same example command
# It indexes (but not commits)
# curl http://localhost:8983/solr/json_tp/update/json -v -d '\{commit:{}}
# The core now contains only one document with auto-generated "id" and
"_version_" field (because we have mapUniqueKeyOnly in params.json)
Attempt 4, removing more keys
# Update params.json to remove mapUniqueKeyOnly
# Same example command
# Indexing fails with: *"msg":"Document is missing mandatory uniqueKey field:
id"*
There does not seem to be way to index the nested JSON using the transformer
approach.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12864) Custom JSON parser's echo parameter does not show values
[
https://issues.apache.org/jira/browse/SOLR-12864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16649084#comment-16649084
]
Alexandre Rafalovitch commented on SOLR-12864:
--
Additional strangeness. If the params are just *'echo=true'*, it echos 4 empty
documents. But if it is *'srcField=src=true'*, then it returns everything
correctly (all fields, including src).
> Custom JSON parser's echo parameter does not show values
>
>
> Key: SOLR-12864
> URL: https://issues.apache.org/jira/browse/SOLR-12864
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.5
>Reporter: Alexandre Rafalovitch
>Priority: Major
>
> During parsing custom JSON, the debugging *echo* parameter does not seem to
> to return actually parsed values. Or possibly returns value for id, but not
> the rest.
> Can be reproduced with:
> # bin/solr create -c splittest
> # bin/post -c splittest -params 'mapUniqueKeyOnly=true=text=true'
> -out yes example/exampledocs/books.json
> Results are:
> {noformat}
> POSTing file books.json (application/json) to [base]/json/docs
> {
> "responseHeader":{
> "status":0,
> "QTime":0},
> "docs":[{
> "id":"978-0641723445",
> "text":[]},
> {
> "id":"978-1423103349",
> "text":[]},
> {
> "id":"978-1857995879",
> "text":[]},
> {
> "id":"978-1933988177",
> "text":[]}]}
> {noformat}
> The documents is not created. If echo parameter is removed, the documents are
> created and the text field does contain values which are shown to the user.
> This happens whether or not the schema fields are already created or
> auto-created by the schemaless mode.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12864) Custom JSON parser's echo parameter does not show values
Alexandre Rafalovitch created SOLR-12864:
Summary: Custom JSON parser's echo parameter does not show values
Key: SOLR-12864
URL: https://issues.apache.org/jira/browse/SOLR-12864
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 7.5
Reporter: Alexandre Rafalovitch
During parsing custom JSON, the debugging *echo* parameter does not seem to to
return actually parsed values. Or possibly returns value for id, but not the
rest.
Can be reproduced with:
# bin/solr create -c splittest
# bin/post -c splittest -params 'mapUniqueKeyOnly=true=text=true' -out
yes example/exampledocs/books.json
Results are:
{noformat}
POSTing file books.json (application/json) to [base]/json/docs
{
"responseHeader":{
"status":0,
"QTime":0},
"docs":[{
"id":"978-0641723445",
"text":[]},
{
"id":"978-1423103349",
"text":[]},
{
"id":"978-1857995879",
"text":[]},
{
"id":"978-1933988177",
"text":[]}]}
{noformat}
The documents is not created. If echo parameter is removed, the documents are
created and the text field does contain values which are shown to the user.
This happens whether or not the schema fields are already created or
auto-created by the schemaless mode.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12816) Don't allow RunUpdateProcessorFactory to be set before DistributedUpdateProcessorFactory
[
https://issues.apache.org/jira/browse/SOLR-12816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16642597#comment-16642597
]
Alexandre Rafalovitch commented on SOLR-12816:
--
I did find the passage in the documentation about [URPs that may want to run
after
DistributedUpdateProcessor|https://lucene.apache.org/solr/guide/7_5/update-request-processors.html#atomic-update-processor-factory].
Basically, if they need to operate on the full document even if only atomic
update was sent, they need to be in the chain after the the
DistributedUpdateProcessor (which reconstructs the document).
I think this must be what I was trying to remember.
> Don't allow RunUpdateProcessorFactory to be set before
> DistributedUpdateProcessorFactory
>
>
> Key: SOLR-12816
> URL: https://issues.apache.org/jira/browse/SOLR-12816
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Priority: Major
>
> Here's the problem that came up with a customer call today morning - "My
> documents are not getting replicated to the replicas and the doc counts don't
> match up"
> It was a 3 node cluster. The collection was 1 shard X 3 replicas .
> This is a scary situation to be in. We started down the patch of debugging
> replica types , auto-commits , checking if the {{_version_}} field and
> {{id}} fields were defined correctly etc.
>
> The problem was the user had defined a custom update processor chain and had
> RunUpdateProcessorFactory defined before DistributedUpdateProcessorFactory
> {code:java}
>
>
>
>
> {code}
>
> With this update chain, whichever node you index the document against will be
> the only one indexing the document. It will never forward to the other nodes.
> So you can index against a node hosting a replica and the leader will never
> get this document.
> Is there any use-case where having RunUpdateProcessor before
> DistributedUpdateProcessor is needed?
>
> Perhaps we could borrow the idea from TRA or make these two update processors
> default and remove them from the default configs?
> {code:java}
> When processing an update for a TRA, Solr initializes its
> UpdateRequestProcessor chain as usual, but when DistributedUpdateProcessor
> (DUP) initializes, it detects that the update targets a TRA and injects
> TimeRoutedUpdateProcessor (TRUP) in front of itself.{code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1913) QParserPlugin plugin for Search Results Filtering Based on Bitwise Operations on Integer Fields
[
https://issues.apache.org/jira/browse/SOLR-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16633576#comment-16633576
]
Alexandre Rafalovitch commented on SOLR-1913:
-
I see AND/OR/XOR in the latest Solr's function Queries.
Does that mean this case can be closed as implemented?
> QParserPlugin plugin for Search Results Filtering Based on Bitwise Operations
> on Integer Fields
> ---
>
> Key: SOLR-1913
> URL: https://issues.apache.org/jira/browse/SOLR-1913
> Project: Solr
> Issue Type: New Feature
> Components: search
>Reporter: Israel Ekpo
>Priority: Major
> Fix For: 4.9, 6.0
>
> Attachments: SOLR-1913-src.tar.gz, SOLR-1913.bitwise.tar.gz,
> SOLR-1913.patch, WEB-INF lib.jpg, bitwise_filter_plugin.jar,
> solr-bitwise-plugin.jar
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> BitwiseQueryParserPlugin is a org.apache.solr.search.QParserPlugin that
> allows
> users to filter the documents returned from a query
> by performing bitwise operations between a particular integer field in the
> index
> and the specified value.
> This Solr plugin is based on the BitwiseFilter in LUCENE-2460
> See https://issues.apache.org/jira/browse/LUCENE-2460 for more details
> This is the syntax for searching in Solr:
> http://localhost:8983/path/to/solr/select/?q={!bitwise field=fieldname
> op=OPERATION_NAME source=sourcevalue negate=boolean}remainder of query
> Example :
> http://localhost:8983/solr/bitwise/select/?q={!bitwise field=user_permissions
> op=AND source=3 negate=true}state:FL
> The negate parameter is optional
> The field parameter is the name of the integer field
> The op parameter is the name of the operation; one of {AND, OR, XOR}
> The source parameter is the specified integer value
> The negate parameter is a boolean indicating whether or not to negate the
> results of the bitwise operation
> To test out this plugin, simply copy the jar file containing the plugin
> classes into your $SOLR_HOME/lib directory and then
> add the following to your solrconfig.xml file after the dismax request
> handler:
> class="org.apache.solr.bitwise.BitwiseQueryParserPlugin" basedOn="dismax" />
> Restart your servlet container.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12816) Don't allow RunUpdateProcessorFactory to be set before DistributedUpdateProcessorFactory
[
https://issues.apache.org/jira/browse/SOLR-12816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16633108#comment-16633108
]
Alexandre Rafalovitch commented on SOLR-12816:
--
I tried to find the use-case, but the only ones I can seem to be relying on
_UpdateRequestProcessorFactory.RunAlways_ instead. So I probably mis-remembered.
The default solrconfig seesm to use a mix of new and old syntax, perhaps to
support the schemaless mode enabling/disabling.
> Don't allow RunUpdateProcessorFactory to be set before
> DistributedUpdateProcessorFactory
>
>
> Key: SOLR-12816
> URL: https://issues.apache.org/jira/browse/SOLR-12816
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Priority: Major
>
> Here's the problem that came up with a customer call today morning - "My
> documents are not getting replicated to the replicas and the doc counts don't
> match up"
> It was a 3 node cluster. The collection was 1 shard X 3 replicas .
> This is a scary situation to be in. We started down the patch of debugging
> replica types , auto-commits , checking if the {{_version_}} field and
> {{id}} fields were defined correctly etc.
>
> The problem was the user had defined a custom update processor chain and had
> RunUpdateProcessorFactory defined before DistributedUpdateProcessorFactory
> {code:java}
>
>
>
>
> {code}
>
> With this update chain, whichever node you index the document against will be
> the only one indexing the document. It will never forward to the other nodes.
> So you can index against a node hosting a replica and the leader will never
> get this document.
> Is there any use-case where having RunUpdateProcessor before
> DistributedUpdateProcessor is needed?
>
> Perhaps we could borrow the idea from TRA or make these two update processors
> default and remove them from the default configs?
> {code:java}
> When processing an update for a TRA, Solr initializes its
> UpdateRequestProcessor chain as usual, but when DistributedUpdateProcessor
> (DUP) initializes, it detects that the update targets a TRA and injects
> TimeRoutedUpdateProcessor (TRUP) in front of itself.{code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12816) Don't allow RunUpdateProcessorFactory to be set before DistributedUpdateProcessorFactory
[
https://issues.apache.org/jira/browse/SOLR-12816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16632257#comment-16632257
]
Alexandre Rafalovitch commented on SOLR-12816:
--
I think the issue was that some URPs can be injected between those two and have
a choice to be handled centrally or per-node.
Also, I could have sworn, we are already injecting one of them if missing.
But maybe there is a use-case for default situation and then recognize an
explicit one with the extra check.
Of course, if new style processor attribute is used, they are already default.
> Don't allow RunUpdateProcessorFactory to be set before
> DistributedUpdateProcessorFactory
>
>
> Key: SOLR-12816
> URL: https://issues.apache.org/jira/browse/SOLR-12816
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Priority: Major
>
> Here's the problem that came up with a customer call today morning - "My
> documents are not getting replicated to the replicas and the doc counts don't
> match up"
> It was a 3 node cluster. The collection was 1 shard X 3 replicas .
> This is a scary situation to be in. We started down the patch of debugging
> replica types , auto-commits , checking if the {{_version_}} field and
> {{id}} fields were defined correctly etc.
>
> The problem was the user had defined a custom update processor chain and had
> RunUpdateProcessorFactory defined before DistributedUpdateProcessorFactory
> {code:java}
>
>
>
>
> {code}
>
> With this update chain, whichever node you index the document against will be
> the only one indexing the document. It will never forward to the other nodes.
> So you can index against a node hosting a replica and the leader will never
> get this document.
> Is there any use-case where having RunUpdateProcessor before
> DistributedUpdateProcessor is needed?
>
> Perhaps we could borrow the idea from TRA or make these two update processors
> default and remove them from the default configs?
> {code:java}
> When processing an update for a TRA, Solr initializes its
> UpdateRequestProcessor chain as usual, but when DistributedUpdateProcessor
> (DUP) initializes, it detects that the update targets a TRA and injects
> TimeRoutedUpdateProcessor (TRUP) in front of itself.{code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12798) Structural changes in SolrJ since version 7.0.0 have effectively disabled multipart post
[ https://issues.apache.org/jira/browse/SOLR-12798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628903#comment-16628903 ] Alexandre Rafalovitch commented on SOLR-12798: -- Karl, we totally believe you that it is happening. We just don't have enough knowledge about your use cases to easily visualize our side of it. I think one or two simple examples would be sufficient, no need to do an all-point. Clearly, even though your use-case was working for a long time, we somehow missed it in our tests/reasoning. So, this discussion is explicitly trying to do better on it than the last time. > Structural changes in SolrJ since version 7.0.0 have effectively disabled > multipart post > > > Key: SOLR-12798 > URL: https://issues.apache.org/jira/browse/SOLR-12798 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Affects Versions: 7.4 >Reporter: Karl Wright >Assignee: Karl Wright >Priority: Major > > Project ManifoldCF uses SolrJ to post documents to Solr. When upgrading from > SolrJ 7.0.x to SolrJ 7.4, we encountered significant structural changes to > SolrJ's HttpSolrClient class that seemingly disable any use of multipart > post. This is critical because ManifoldCF's documents often contain metadata > in excess of 4K that therefore cannot be stuffed into a URL. > The changes in question seem to have been performed by Paul Noble on > 10/31/2017, with the introduction of the RequestWriter mechanism. Basically, > if a request has a RequestWriter, it is used exclusively to write the > request, and that overrides the stream mechanism completely. I haven't > chased it back to a specific ticket. > ManifoldCF's usage of SolrJ involves the creation of > ContentStreamUpdateRequests for all posts meant for Solr Cell, and the > creation of UpdateRequests for posts not meant for Solr Cell (as well as for > delete and commit requests). For our release cycle that is taking place > right now, we're shipping a modified version of HttpSolrClient that ignores > the RequestWriter when dealing with ContentStreamUpdateRequests. We > apparently cannot use multipart for all requests because on the Solr side we > get "pfountz Should not get here!" errors on the Solr side when we do, which > generate HTTP error code 500 responses. That should not happen either, in my > opinion. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12798) Structural changes in SolrJ since version 7.0.0 have effectively disabled multipart post
[ https://issues.apache.org/jira/browse/SOLR-12798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628813#comment-16628813 ] Alexandre Rafalovitch commented on SOLR-12798: -- [~kwri...@metacarta.com] I am with Shalin on this. While I appreciate that MCF (which we do refer people to from Solr) is very general framework, I think it would be very useful to have a concrete sample example that shows what kind of information actually goes to the wire. Specifically the example that generates meaningful metadata and body (multipart) both of which are ending-up used in Solr. This would really help us to visualize the kind of use-cases, that are very obvious to your project. The link example was about forcing multipart, so was not quite representative. Similarly, Tika generates one part with all parameters. An example that has 2 (3?) meaningful parts would be most helpful I feel. And maybe even something that could go into a Solr test (so does not need to be very long, just truly multipart). > Structural changes in SolrJ since version 7.0.0 have effectively disabled > multipart post > > > Key: SOLR-12798 > URL: https://issues.apache.org/jira/browse/SOLR-12798 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Affects Versions: 7.4 >Reporter: Karl Wright >Assignee: Karl Wright >Priority: Major > > Project ManifoldCF uses SolrJ to post documents to Solr. When upgrading from > SolrJ 7.0.x to SolrJ 7.4, we encountered significant structural changes to > SolrJ's HttpSolrClient class that seemingly disable any use of multipart > post. This is critical because ManifoldCF's documents often contain metadata > in excess of 4K that therefore cannot be stuffed into a URL. > The changes in question seem to have been performed by Paul Noble on > 10/31/2017, with the introduction of the RequestWriter mechanism. Basically, > if a request has a RequestWriter, it is used exclusively to write the > request, and that overrides the stream mechanism completely. I haven't > chased it back to a specific ticket. > ManifoldCF's usage of SolrJ involves the creation of > ContentStreamUpdateRequests for all posts meant for Solr Cell, and the > creation of UpdateRequests for posts not meant for Solr Cell (as well as for > delete and commit requests). For our release cycle that is taking place > right now, we're shipping a modified version of HttpSolrClient that ignores > the RequestWriter when dealing with ContentStreamUpdateRequests. We > apparently cannot use multipart for all requests because on the Solr side we > get "pfountz Should not get here!" errors on the Solr side when we do, which > generate HTTP error code 500 responses. That should not happen either, in my > opinion. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12798) Structural changes in SolrJ since version 7.0.0 have effectively disabled multipart post
[ https://issues.apache.org/jira/browse/SOLR-12798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16627589#comment-16627589 ] Alexandre Rafalovitch commented on SOLR-12798: -- As far as I understand, we do advertise multipart upload in several places: * [https://lucene.apache.org/solr/guide/7_5/content-streams.html#content-stream-sources] * multipartUploadLimitInKB parameter in solrconfig.xml [https://lucene.apache.org/solr/guide/7_5/requestdispatcher-in-solrconfig.html#requestparsers-element] If the current issue changes those expectations without explicitly discussing them and including the new user-visible limitation in the migration guide for 7.5, we have a clear case of critical regression on our hands. I cannot see any tests in the codebases for this, but - if my assessment is correct - perhaps one should exist. > Structural changes in SolrJ since version 7.0.0 have effectively disabled > multipart post > > > Key: SOLR-12798 > URL: https://issues.apache.org/jira/browse/SOLR-12798 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Affects Versions: 7.4 >Reporter: Karl Wright >Priority: Major > > Project ManifoldCF uses SolrJ to post documents to Solr. When upgrading from > SolrJ 7.0.x to SolrJ 7.4, we encountered significant structural changes to > SolrJ's HttpSolrClient class that seemingly disable any use of multipart > post. This is critical because ManifoldCF's documents often contain metadata > in excess of 4K that therefore cannot be stuffed into a URL. > The changes in question seem to have been performed by Paul Noble on > 10/31/2017, with the introduction of the RequestWriter mechanism. Basically, > if a request has a RequestWriter, it is used exclusively to write the > request, and that overrides the stream mechanism completely. I haven't > chased it back to a specific ticket. > ManifoldCF's usage of SolrJ involves the creation of > ContentStreamUpdateRequests for all posts meant for Solr Cell, and the > creation of UpdateRequests for posts not meant for Solr Cell (as well as for > delete and commit requests). For our release cycle that is taking place > right now, we're shipping a modified version of HttpSolrClient that ignores > the RequestWriter when dealing with ContentStreamUpdateRequests. We > apparently cannot use multipart for all requests because on the Solr side we > get "pfountz Should not get here!" errors on the Solr side when we do, which > generate HTTP error code 500 responses. That should not happen either, in my > opinion. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12789) UIMA enhancements to allow for dynamic AE detection
[ https://issues.apache.org/jira/browse/SOLR-12789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16623756#comment-16623756 ] Alexandre Rafalovitch commented on SOLR-12789: -- Hi Aaron, It is great to hear that there would be a healthy discussion about this. Please feel free to share the outcome of this on the developer list and it may spark further developers discussion too. Nothing is set in stone, given enough evidence to the contrary. Still, just to re-summarize, the issue we were facing was that all the shipped examples were dead (Alchemy API...) and over multiple issues we could not figure out a way to get to the new local maximum of latest version and useful examples (UIMA has a bit of a learning curve). Nor were we able to find anybody helping us to push the discussion forward within either development community (Jira discussions) or the user community (Solr Users mailing list). Additionally, we are trying to slim Solr down in general and have done several things towards that, including removing Javadoc from the distribution. If you were more closely connected to the community, you would see multiple of these drives all pointing in the same general direction. So, having a dead weight we could not figure what to do with over several years was very much "not cool" on all those users downloading Solr and trying to navigate their way through very full-featured product. And then, of course, there is a fact that we now incorporate Apache OpenNLP as well. So, there are trade-offs to keep in mind. > UIMA enhancements to allow for dynamic AE detection > --- > > Key: SOLR-12789 > URL: https://issues.apache.org/jira/browse/SOLR-12789 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - UIMA >Affects Versions: 6.0 >Reporter: Aaron LaBella >Priority: Major > Labels: ready-to-commit > Attachments: SOLR-12789-1.patch, SOLR-12789-2.patch, > SOLR-12789-3.patch > > > I've been sitting on this patch for over 2 years (and likewise it's been > running IN production for the same) ... finally got around to contributing it > back to the community. This change prepares the UIMAUpdateRequestProcessor > to allow subclasses to have additional control over how the analysis engine > is selected. In my case, I wrote a sub-class that allows for *dynamic* > detection of the UIMA analysis engine based on the document fields. ie: a > field in the document can be used to select different UIMA configurations and > rules. > > Can someone please commit this as soon as possible. I don't necessarily need > it to be back-ported, having in 7.4.1 would suffice. > Thanks! -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11694) Remove extremely outdated UIMA contrib module
[ https://issues.apache.org/jira/browse/SOLR-11694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622691#comment-16622691 ] Alexandre Rafalovitch commented on SOLR-11694: -- I think the proper indexing pipeline is already the Apache NiFi or Apache Camel. Both are our sister projects that do have some support for Solr. So to me, the really correct thing would be to get really close to one or both of them and ensure they cover all our use cases and their Solr integration is top notch. I think that building a bridge between two large cities/projects is better than trying to grow our own city satellite. > Remove extremely outdated UIMA contrib module > - > > Key: SOLR-11694 > URL: https://issues.apache.org/jira/browse/SOLR-11694 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - UIMA >Reporter: Cassandra Targett >Assignee: Alexandre Rafalovitch >Priority: Major > Fix For: 7.5, master (8.0) > > Attachments: SOLR-11694.patch > > > A user on the [solr-user mailing list back in > June|https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201706.mbox/%3CCANsk%2BC_PvZJ38AQ2VfzKRYSQn6c8b33kGvaXxR3qNS3GQ4VUKA%40mail.gmail.com%3E] > brought up the fact that IBM has bought Alchemy and keys are no longer > available to use Solr's UIMA contrib. > Someone recently made a [similar > comment|https://lucene.apache.org/solr/guide/7_1/uima-integration.html#comment_7174] > to the Solr Ref Guide page and asking for a patch. > I know next to nothing about UIMA, but figured it's worth an issue to > determine what to do here. I think folks are saying it's no longer usable? Or > maybe only usable by people who already have keys (which will possibly expire > at some point)? > Anyone have an idea what needs to be done here? It seems we should have some > kind of answer, but if it's no longer usable perhaps we should retire the > contrib. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11694) Remove extremely outdated UIMA contrib module
[ https://issues.apache.org/jira/browse/SOLR-11694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622663#comment-16622663 ] Alexandre Rafalovitch commented on SOLR-11694: -- Here is a couple of decision points that went into this: # I made a call for UIMA use cases on the Solr Users mailing list and got zero positive replies. # UIMA version 2.8 was released in May 2016 # The current version of UIMA is 3.x, with a completely different infrastructure # We had integration points that no longer worked for very long time # I think you probably can still use UIMA as your own custom module, most of the integration I deleted was to get it to build and ship (and all the dead examples). I would say a contribution that upgrades UIMA to the latest 3.x version with at least rudimentary example/documentation would be viewed positively. However, it does not seem to be what is being offered here. So, I am -0 on the proposal to just reverse. Others may have a different opinion. > Remove extremely outdated UIMA contrib module > - > > Key: SOLR-11694 > URL: https://issues.apache.org/jira/browse/SOLR-11694 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - UIMA >Reporter: Cassandra Targett >Assignee: Alexandre Rafalovitch >Priority: Major > Fix For: 7.5, master (8.0) > > Attachments: SOLR-11694.patch > > > A user on the [solr-user mailing list back in > June|https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201706.mbox/%3CCANsk%2BC_PvZJ38AQ2VfzKRYSQn6c8b33kGvaXxR3qNS3GQ4VUKA%40mail.gmail.com%3E] > brought up the fact that IBM has bought Alchemy and keys are no longer > available to use Solr's UIMA contrib. > Someone recently made a [similar > comment|https://lucene.apache.org/solr/guide/7_1/uima-integration.html#comment_7174] > to the Solr Ref Guide page and asking for a patch. > I know next to nothing about UIMA, but figured it's worth an issue to > determine what to do here. I think folks are saying it's no longer usable? Or > maybe only usable by people who already have keys (which will possibly expire > at some point)? > Anyone have an idea what needs to be done here? It seems we should have some > kind of answer, but if it's no longer usable perhaps we should retire the > contrib. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12789) UIMA enhancements to allow for dynamic AE detection
[ https://issues.apache.org/jira/browse/SOLR-12789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622329#comment-16622329 ] Alexandre Rafalovitch commented on SOLR-12789: -- UIMA has been removed as of Solr 7.5, as it was incredible out of date and the UIMA architecture itself has changed significantly. See SOLR-11694. I am not quite sure there is a viable next step for this. Especially, not as a blocker for a version that is no longer supported beyond security fixes. > UIMA enhancements to allow for dynamic AE detection > --- > > Key: SOLR-12789 > URL: https://issues.apache.org/jira/browse/SOLR-12789 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - UIMA >Affects Versions: 6.0 >Reporter: Aaron LaBella >Priority: Blocker > Labels: ready-to-commit > Attachments: SOLR-12789-1.patch, SOLR-12789-2.patch, > SOLR-12789-3.patch > > > I've been sitting on this patch for over 2 years (and likewise it's been > running IN production for the same) ... finally got around to contributing it > back to the community. This change prepares the UIMAUpdateRequestProcessor > to allow subclasses to have additional control over how the analysis engine > is selected. In my case, I wrote a sub-class that allows for *dynamic* > detection of the UIMA analysis engine based on the document fields. ie: a > field in the document can be used to select different UIMA configurations and > rules. > > Can someone please commit this as soon as possible. I don't necessarily need > it to be back-ported, having in 7.4.1 would suffice. > Thanks! -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12549) Settle a location for the log4j2.xml file
[ https://issues.apache.org/jira/browse/SOLR-12549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16618037#comment-16618037 ] Alexandre Rafalovitch commented on SOLR-12549: -- 7.5 Release notes still refer to the 12008, but now that it is deleted, nobody would be able to find further details on it. Not sure what the best way to fix it is. Maybe just relink it to this one? > Settle a location for the log4j2.xml file > - > > Key: SOLR-12549 > URL: https://issues.apache.org/jira/browse/SOLR-12549 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: logging >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Fix For: 7.5, master (8.0) > > Attachments: SOLR-12008-7x-test-fail-fix.patch, SOLR-12008.patch, > SOLR-12008.patch, SOLR-12008.patch, SOLR-12008.patch, SOLR-12008.patch > > > CLONED from SOLR-12008 since 12008 couldn't be closed. > As part of SOLR-11934 I started looking at log4j.properties files. Waaay back > in 2015, the %C in "/solr/server/resources/log4j.properties" was changed to > use %c, but the file in "solr/example/resources/log4j.properties" was not > changed. That got me to looking around and there are a bunch of > log4j.properties files: > ./solr/core/src/test-files/log4j.properties > ./solr/example/resources/log4j.properties > ./solr/solrj/src/test-files/log4j.properties > ./solr/server/resources/log4j.properties > ./solr/server/scripts/cloud-scripts/log4j.properties > ./solr/contrib/dataimporthandler/src/test-files/log4j.properties > ./solr/contrib/clustering/src/test-files/log4j.properties > ./solr/contrib/ltr/src/test-files/log4j.properties > ./solr/test-framework/src/test-files/log4j.properties > Why do we have so many? After the log4j2 ticket gets checked in (SOLR-7887) I > propose the logging configuration files get consolidated. The question is > "how far"? > I at least want to get rid of the one in solr/example, users should use the > one in server/resources. Having to maintain these two separately is asking > for trouble. > [~markrmil...@gmail.com] Do you have any wisdom on the properties file in > server/scripts/cloud-scripts? > Anyone else who has a clue about why the other properties files were created, > especially the ones in contrib? > And what about all the ones in various test-files directories? People didn't > create them for no reason, and I don't want to rediscover that it's a real > pain to try to re-use the one in server/resources for instance. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12769) Incorrect documentation for Request Parameter API names (unset/delete)
Alexandre Rafalovitch created SOLR-12769: Summary: Incorrect documentation for Request Parameter API names (unset/delete) Key: SOLR-12769 URL: https://issues.apache.org/jira/browse/SOLR-12769 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Components: documentation Affects Versions: 7.4 Reporter: Alexandre Rafalovitch The [documentation for the Request Parameter APIhttps://lucene.apache.org/solr/guide/7_4/request-parameters-api.html#setting-request-parameters] names operations as set/update/unset. So does the introspection. However, the code for the SolrConfigHandler#handleParams uses set/update/delete. So, the *unset* is not a correct description. The manual testing also shows only *delete* command working. Furthermore, the format of the delete command is different from others (array, not map), so this should be documented as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7321) Character Mapping
[ https://issues.apache.org/jira/browse/LUCENE-7321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594099#comment-16594099 ] Alexandre Rafalovitch commented on LUCENE-7321: --- This feels a little bit like too many use-cases folded into one piece of code. Arabic, Japanese, Korean names special handling, Russian already covered by the stemmer. I am not sure what the clean use-case is here. Especially with say [PatternReplaceCharFilterFactory|http://www.solr-start.com/javadoc/solr-lucene/org/apache/lucene/analysis/pattern/PatternReplaceCharFilterFactory.html] being there to cover possible special use-case gaps (at a lower performance perhaps). And with ICU4J possibly covering others. > Character Mapping > - > > Key: LUCENE-7321 > URL: https://issues.apache.org/jira/browse/LUCENE-7321 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.6.1, 5.4.1, 6.0, 6.0.1 >Reporter: Ivan Provalov >Priority: Minor > Labels: patch > Fix For: 6.0.1 > > Attachments: CharacterMappingComponent.pdf, LUCENE-7321.patch > > > One of the challenges in search is recall of an item with a common typing > variant. These cases can be as simple as lower/upper case in most languages, > accented characters, or more complex morphological phenomena like prefix > omitting, or constructing a character with some combining mark. This > component addresses the cases, which are not covered by ASCII folding > component, or more complex to design with other tools. The idea is that a > linguist could provide the mappings in a tab-delimited file, which then can > be directly used by Solr. > The mappings are maintained in the tab-delimited file, which could be just a > copy paste from Excel spreadsheet. This gives the linguists the opportunity > to create the mappings, then for the developer to include them in Solr > configuration. There are a few cases, when the mappings grow complex, where > some additional debugging may be required. The mappings can contain any > sequence of characters to any other sequence of characters. > Some of the cases I discuss in detail document are handling the voiced vowels > for Japanese; common typing substitutions for Korean, Russian, Polish; > transliteration for Polish, Arabic; prefix removal for Arabic; suffix folding > for Japanese. In the appendix, I give an example of implementing a Russian > light weight stemmer using this component. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12600) Parameters mapping for query parameters to JSON query
[ https://issues.apache.org/jira/browse/SOLR-12600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16576297#comment-16576297 ] Alexandre Rafalovitch commented on SOLR-12600: -- That's the correct source file yes. Do the patch/pull-request for that (mention this issue as SOLR- if pull-request) and it will be against the latest (currently 8) version. I can verify and then port it to version 7.x. > Parameters mapping for query parameters to JSON query > - > > Key: SOLR-12600 > URL: https://issues.apache.org/jira/browse/SOLR-12600 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Affects Versions: 7.4 >Reporter: Renuka Srishti >Assignee: Alexandre Rafalovitch >Priority: Minor > > Paramters mapping mentioned here is not right. > start, rows works for standard query parameters. > offset, limit works for JSON query. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-12569) Document SignificantTermsQParserPlugin
[ https://issues.apache.org/jira/browse/SOLR-12569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandre Rafalovitch closed SOLR-12569. Ok. If this was not intended for the users, then the whole Jira can be ignored. > Document SignificantTermsQParserPlugin > -- > > Key: SOLR-12569 > URL: https://issues.apache.org/jira/browse/SOLR-12569 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Alexandre Rafalovitch >Assignee: Alexandre Rafalovitch >Priority: Major > Attachments: SOLR-12569.patch > > > SignificantTermsQParserPlugin was introduced at the same as significantTerms > stream source, but only the stream source was documented. > QParser should be documented too, especially since it can be used in > non-cloud mode and has to be used as fq (otherwise, it throws exception). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-12569) Document SignificantTermsQParserPlugin
[ https://issues.apache.org/jira/browse/SOLR-12569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandre Rafalovitch resolved SOLR-12569. -- Resolution: Invalid > Document SignificantTermsQParserPlugin > -- > > Key: SOLR-12569 > URL: https://issues.apache.org/jira/browse/SOLR-12569 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Alexandre Rafalovitch >Assignee: Alexandre Rafalovitch >Priority: Major > Attachments: SOLR-12569.patch > > > SignificantTermsQParserPlugin was introduced at the same as significantTerms > stream source, but only the stream source was documented. > QParser should be documented too, especially since it can be used in > non-cloud mode and has to be used as fq (otherwise, it throws exception). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Reopened] (SOLR-12569) Document SignificantTermsQParserPlugin
[ https://issues.apache.org/jira/browse/SOLR-12569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandre Rafalovitch reopened SOLR-12569: -- > Document SignificantTermsQParserPlugin > -- > > Key: SOLR-12569 > URL: https://issues.apache.org/jira/browse/SOLR-12569 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Alexandre Rafalovitch >Assignee: Alexandre Rafalovitch >Priority: Major > Attachments: SOLR-12569.patch > > > SignificantTermsQParserPlugin was introduced at the same as significantTerms > stream source, but only the stream source was documented. > QParser should be documented too, especially since it can be used in > non-cloud mode and has to be used as fq (otherwise, it throws exception). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-12569) Document SignificantTermsQParserPlugin
[ https://issues.apache.org/jira/browse/SOLR-12569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandre Rafalovitch resolved SOLR-12569. -- Resolution: Later Keep the QParser undocumented for now, as the functionality is not fully baked yet. > Document SignificantTermsQParserPlugin > -- > > Key: SOLR-12569 > URL: https://issues.apache.org/jira/browse/SOLR-12569 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Alexandre Rafalovitch >Assignee: Alexandre Rafalovitch >Priority: Major > Attachments: SOLR-12569.patch > > > SignificantTermsQParserPlugin was introduced at the same as significantTerms > stream source, but only the stream source was documented. > QParser should be documented too, especially since it can be used in > non-cloud mode and has to be used as fq (otherwise, it throws exception). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10705) Upgrade Velocity's version of jquery from 1.7.2 to 2.1.3
[ https://issues.apache.org/jira/browse/SOLR-10705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16573413#comment-16573413 ] Alexandre Rafalovitch commented on SOLR-10705: -- [https://select2.org/] is a popular autocomplete element that uses JQuery and has MIT license. I am +0 on removing Velocity as I feel Velocity project no longer has sufficient community. On the other hand, the Solr example using it demonstrates something we do not really explain/demonstrate in other ways (plugin-style resources loading, etc). For a while I thought we should migrate to [https://www.thymeleaf.org/] but I am no longer sure the server-side in-Solr framework is the right approach. > Upgrade Velocity's version of jquery from 1.7.2 to 2.1.3 > > > Key: SOLR-10705 > URL: https://issues.apache.org/jira/browse/SOLR-10705 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - Velocity >Reporter: Jan Høydahl >Priority: Major > Labels: newdev > > ...in order to avoid shipping both versions. This requires selecting another > autocomplete plugin, since the one in use > https://github.com/agarzola/jQueryAutocompletePlugin is abandoned -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12569) Document SignificantTermsQParserPlugin
[ https://issues.apache.org/jira/browse/SOLR-12569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16573280#comment-16573280 ] Alexandre Rafalovitch commented on SOLR-12569: -- Streaming Expressions are just for SolrCloud mode though, right? Does this not make sense at all for a standalone setup, still a very popular choice? > Document SignificantTermsQParserPlugin > -- > > Key: SOLR-12569 > URL: https://issues.apache.org/jira/browse/SOLR-12569 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Alexandre Rafalovitch >Assignee: Alexandre Rafalovitch >Priority: Major > Attachments: SOLR-12569.patch > > > SignificantTermsQParserPlugin was introduced at the same as significantTerms > stream source, but only the stream source was documented. > QParser should be documented too, especially since it can be used in > non-cloud mode and has to be used as fq (otherwise, it throws exception). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12569) Document SignificantTermsQParserPlugin
[ https://issues.apache.org/jira/browse/SOLR-12569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16573095#comment-16573095 ] Alexandre Rafalovitch commented on SOLR-12569: -- Documentation patch is attached. As it is my first one and for somebody else's code, I would appreciate a review ([~ctargett], [~joel.bernstein]). > Document SignificantTermsQParserPlugin > -- > > Key: SOLR-12569 > URL: https://issues.apache.org/jira/browse/SOLR-12569 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Alexandre Rafalovitch >Assignee: Alexandre Rafalovitch >Priority: Major > Attachments: SOLR-12569.patch > > > SignificantTermsQParserPlugin was introduced at the same as significantTerms > stream source, but only the stream source was documented. > QParser should be documented too, especially since it can be used in > non-cloud mode and has to be used as fq (otherwise, it throws exception). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12569) Document SignificantTermsQParserPlugin
[ https://issues.apache.org/jira/browse/SOLR-12569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandre Rafalovitch updated SOLR-12569: - Attachment: SOLR-12569.patch > Document SignificantTermsQParserPlugin > -- > > Key: SOLR-12569 > URL: https://issues.apache.org/jira/browse/SOLR-12569 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Alexandre Rafalovitch >Assignee: Alexandre Rafalovitch >Priority: Major > Attachments: SOLR-12569.patch > > > SignificantTermsQParserPlugin was introduced at the same as significantTerms > stream source, but only the stream source was documented. > QParser should be documented too, especially since it can be used in > non-cloud mode and has to be used as fq (otherwise, it throws exception). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-12574) SignificantTermsQParserPlugin should output its keys in a combined bucket
[
https://issues.apache.org/jira/browse/SOLR-12574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandre Rafalovitch resolved SOLR-12574.
--
Resolution: Fixed
Fix backported.
> SignificantTermsQParserPlugin should output its keys in a combined bucket
> -
>
> Key: SOLR-12574
> URL: https://issues.apache.org/jira/browse/SOLR-12574
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Affects Versions: 7.4
>Reporter: Alexandre Rafalovitch
>Assignee: Alexandre Rafalovitch
>Priority: Minor
> Fix For: 7.5
>
> Attachments: SOLR-12574.patch
>
>
> SignificantTermsQParserPlugin is not yet visible to the users (was not
> documented or spelt correctly in 7.4), so there is still a chance to fix its
> output before people start using it.
> Currently, it injects 6 different keys into the document, on the same level
> as responseHeader and response. This feels like polluting top-level space. It
> may be better to put all those keys under one bucket (e.g. significantTerms).
> Additionally, resultCount is always the same as response.numFound (documents
> found), so does not seem to be needed.
> Current output:
> {code:java}
> {
> "responseHeader": {
> "status": 0,
> "QTime": 1,
> "params": {
> "q": "directed_by_str:\"Steven Soderbergh\"",
> "fq": "{!significantTerms field=genre numTerms=2}",
> "rows": "1",
> "wt": "json"
> }
> },
> "numDocs": 1100,
> "resultCount": 5,
> "sterms": [
> "biographical",
> "romance"
> ],
> "scores": [
> 2.5552773475646973,
> 2.6387078762054443
> ],
> "docFreq": [
> 74,
> 270
> ],
> "queryDocFreq": [
> 2,
> 3
> ],
> "response": {
> "numFound": 5,
> "start": 0,
> "docs": [
> {
> "id": "/en/bubble",
> "directed_by": [
> "Steven Soderbergh"
> ],
> "initial_release_date": "2005-09-03T00:00:00Z",
> "name": "Bubble",
> "genre": [
> "Crime Fiction",
> "Mystery",
> "Indie film",
> "Thriller",
> "Drama"
> ],
> "_version_": 1606610059993808899
> }
> ]
> }
> }{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-5332) Add "preserve original" setting to the EdgeNGramFilterFactory
[ https://issues.apache.org/jira/browse/SOLR-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandre Rafalovitch closed SOLR-5332. --- > Add "preserve original" setting to the EdgeNGramFilterFactory > - > > Key: SOLR-5332 > URL: https://issues.apache.org/jira/browse/SOLR-5332 > Project: Solr > Issue Type: Wish >Affects Versions: 4.4, 4.5, 4.5.1, 4.6 >Reporter: Alexander S. >Priority: Major > > Hi, as described here: > http://lucene.472066.n3.nabble.com/Help-to-figure-out-why-query-does-not-match-td4086967.html > the problem is in that if you have these 2 strings to index: > 1. facebook.com/someuser.1 > 2. facebook.com/someveryandverylongusername > and the edge ngram filter factory with min and max gram size settings 2 and > 25, search requests for these urls will fail. > But search requests for: > 1. facebook.com/someuser > 2. facebook.com/someveryandverylonguserna > will work properly. > It's because first url has "1" at the end, which is lover than the allowed > min gram size. In the second url the user name is longer than the max gram > size (27 characters). > Would be good to have a "preserve original" option, that will add the > original string to the index if it does not fit the allowed gram size, so > that "1" and "someveryandverylongusername" tokens will also be added to the > index. > Best, > Alex -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-5332) Add "preserve original" setting to the EdgeNGramFilterFactory
[ https://issues.apache.org/jira/browse/SOLR-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandre Rafalovitch resolved SOLR-5332. - Resolution: Implemented Fix Version/s: (was: 6.0) (was: 5.2) It seems most of this has been implemented in other, already referenced issues. It is not clear what is left to do here. I suggest a new issue is opened with latest needs, if any still exist in the current Solr version. > Add "preserve original" setting to the EdgeNGramFilterFactory > - > > Key: SOLR-5332 > URL: https://issues.apache.org/jira/browse/SOLR-5332 > Project: Solr > Issue Type: Wish >Affects Versions: 4.4, 4.5, 4.5.1, 4.6 >Reporter: Alexander S. >Priority: Major > > Hi, as described here: > http://lucene.472066.n3.nabble.com/Help-to-figure-out-why-query-does-not-match-td4086967.html > the problem is in that if you have these 2 strings to index: > 1. facebook.com/someuser.1 > 2. facebook.com/someveryandverylongusername > and the edge ngram filter factory with min and max gram size settings 2 and > 25, search requests for these urls will fail. > But search requests for: > 1. facebook.com/someuser > 2. facebook.com/someveryandverylonguserna > will work properly. > It's because first url has "1" at the end, which is lover than the allowed > min gram size. In the second url the user name is longer than the max gram > size (27 characters). > Would be good to have a "preserve original" option, that will add the > original string to the index if it does not fit the allowed gram size, so > that "1" and "someveryandverylongusername" tokens will also be added to the > index. > Best, > Alex -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-5152) EdgeNGramFilterFactory deletes token
[
https://issues.apache.org/jira/browse/SOLR-5152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandre Rafalovitch closed SOLR-5152.
---
Has been resolved (duplicate) a while ago.
> EdgeNGramFilterFactory deletes token
>
>
> Key: SOLR-5152
> URL: https://issues.apache.org/jira/browse/SOLR-5152
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 4.4
>Reporter: Christoph Lingg
>Priority: Major
> Attachments: SOLR-5152-v5.0.0.patch, SOLR-5152.patch
>
>
> I am using EdgeNGramFilterFactory in my schema.xml
> {code:xml} positionIncrementGap="100">
>
>
> maxGramSize="10" side="front" />
>
> {code}
> Some tokens in my index only consist of one character, let's say {{R}}.
> minGramSize is set to 2 and is bigger than the length of the token. I
> expected the NGramFilter to left {{R}} unchanged but in fact it is deleting
> the token.
> For my use case this interpretation is undesirable, and probably for most use
> cases too!?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16565717#comment-16565717 ] Alexandre Rafalovitch commented on LUCENE-2562: --- I just meant that Lucene does not have a server+HTML+CSS, so any UI addition will be a non-trivial discussion. I did not have any deeper insight than that. > Make Luke a Lucene/Solr Module > -- > > Key: LUCENE-2562 > URL: https://issues.apache.org/jira/browse/LUCENE-2562 > Project: Lucene - Core > Issue Type: Task >Reporter: Mark Miller >Priority: Major > Labels: gsoc2014 > Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, > LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, > LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, > Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png, > luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png > > Time Spent: 20m > Remaining Estimate: 0h > > see > "RE: Luke - in need of maintainer": > http://markmail.org/message/m4gsto7giltvrpuf > "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q > I think it would be great if there was a version of Luke that always worked > with trunk - and it would also be great if it was easier to match Luke jars > with Lucene versions. > While I'd like to get GWT Luke into the mix as well, I think the easiest > starting point is to straight port Luke to another UI toolkit before > abstracting out DTO objects that both GWT Luke and Pivot Luke could share. > I've started slowly converting Luke's use of thinlet to Apache Pivot. I > haven't/don't have a lot of time for this at the moment, but I've plugged > away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-12603) Create a super-minimal configset
[ https://issues.apache.org/jira/browse/SOLR-12603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandre Rafalovitch reassigned SOLR-12603: Assignee: Alexandre Rafalovitch > Create a super-minimal configset > > > Key: SOLR-12603 > URL: https://issues.apache.org/jira/browse/SOLR-12603 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation, examples >Affects Versions: 7.4 >Reporter: Alexandre Rafalovitch >Assignee: Alexandre Rafalovitch >Priority: Major > > As per discussion on the mailing list, it would be a good idea to create a > super-minimal example. > A prototype is available at > [https://github.com/arafalov/solr-presentation-2018-may/tree/master/configs/initial] > It can be improved by maybe another type (text), using parameter set and > documentation pointing out the missing pieces and where to find them in the > reference guide. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12603) Create a super-minimal configset
Alexandre Rafalovitch created SOLR-12603: Summary: Create a super-minimal configset Key: SOLR-12603 URL: https://issues.apache.org/jira/browse/SOLR-12603 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: documentation, examples Affects Versions: 7.4 Reporter: Alexandre Rafalovitch As per discussion on the mailing list, it would be a good idea to create a super-minimal example. A prototype is available at [https://github.com/arafalov/solr-presentation-2018-may/tree/master/configs/initial] It can be improved by maybe another type (text), using parameter set and documentation pointing out the missing pieces and where to find them in the reference guide. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Reopened] (SOLR-12574) SignificantTermsQParserPlugin should output its keys in a combined bucket
[
https://issues.apache.org/jira/browse/SOLR-12574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandre Rafalovitch reopened SOLR-12574:
--
The solution is not complete yet.
> SignificantTermsQParserPlugin should output its keys in a combined bucket
> -
>
> Key: SOLR-12574
> URL: https://issues.apache.org/jira/browse/SOLR-12574
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Affects Versions: 7.4
>Reporter: Alexandre Rafalovitch
>Assignee: Alexandre Rafalovitch
>Priority: Minor
> Fix For: 7.5
>
> Attachments: SOLR-12574.patch
>
>
> SignificantTermsQParserPlugin is not yet visible to the users (was not
> documented or spelt correctly in 7.4), so there is still a chance to fix its
> output before people start using it.
> Currently, it injects 6 different keys into the document, on the same level
> as responseHeader and response. This feels like polluting top-level space. It
> may be better to put all those keys under one bucket (e.g. significantTerms).
> Additionally, resultCount is always the same as response.numFound (documents
> found), so does not seem to be needed.
> Current output:
> {code:java}
> {
> "responseHeader": {
> "status": 0,
> "QTime": 1,
> "params": {
> "q": "directed_by_str:\"Steven Soderbergh\"",
> "fq": "{!significantTerms field=genre numTerms=2}",
> "rows": "1",
> "wt": "json"
> }
> },
> "numDocs": 1100,
> "resultCount": 5,
> "sterms": [
> "biographical",
> "romance"
> ],
> "scores": [
> 2.5552773475646973,
> 2.6387078762054443
> ],
> "docFreq": [
> 74,
> 270
> ],
> "queryDocFreq": [
> 2,
> 3
> ],
> "response": {
> "numFound": 5,
> "start": 0,
> "docs": [
> {
> "id": "/en/bubble",
> "directed_by": [
> "Steven Soderbergh"
> ],
> "initial_release_date": "2005-09-03T00:00:00Z",
> "name": "Bubble",
> "genre": [
> "Crime Fiction",
> "Mystery",
> "Indie film",
> "Thriller",
> "Drama"
> ],
> "_version_": 1606610059993808899
> }
> ]
> }
> }{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12574) SignificantTermsQParserPlugin should output its keys in a combined bucket
[
https://issues.apache.org/jira/browse/SOLR-12574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16561991#comment-16561991
]
Alexandre Rafalovitch commented on SOLR-12574:
--
Thanks for the catch. The StreamExpression was using Query Parser under the
covers and I missed one link. I'll fix it tonight.
> SignificantTermsQParserPlugin should output its keys in a combined bucket
> -
>
> Key: SOLR-12574
> URL: https://issues.apache.org/jira/browse/SOLR-12574
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Affects Versions: 7.4
>Reporter: Alexandre Rafalovitch
>Assignee: Alexandre Rafalovitch
>Priority: Minor
> Fix For: 7.5
>
> Attachments: SOLR-12574.patch
>
>
> SignificantTermsQParserPlugin is not yet visible to the users (was not
> documented or spelt correctly in 7.4), so there is still a chance to fix its
> output before people start using it.
> Currently, it injects 6 different keys into the document, on the same level
> as responseHeader and response. This feels like polluting top-level space. It
> may be better to put all those keys under one bucket (e.g. significantTerms).
> Additionally, resultCount is always the same as response.numFound (documents
> found), so does not seem to be needed.
> Current output:
> {code:java}
> {
> "responseHeader": {
> "status": 0,
> "QTime": 1,
> "params": {
> "q": "directed_by_str:\"Steven Soderbergh\"",
> "fq": "{!significantTerms field=genre numTerms=2}",
> "rows": "1",
> "wt": "json"
> }
> },
> "numDocs": 1100,
> "resultCount": 5,
> "sterms": [
> "biographical",
> "romance"
> ],
> "scores": [
> 2.5552773475646973,
> 2.6387078762054443
> ],
> "docFreq": [
> 74,
> 270
> ],
> "queryDocFreq": [
> 2,
> 3
> ],
> "response": {
> "numFound": 5,
> "start": 0,
> "docs": [
> {
> "id": "/en/bubble",
> "directed_by": [
> "Steven Soderbergh"
> ],
> "initial_release_date": "2005-09-03T00:00:00Z",
> "name": "Bubble",
> "genre": [
> "Crime Fiction",
> "Mystery",
> "Indie film",
> "Thriller",
> "Drama"
> ],
> "_version_": 1606610059993808899
> }
> ]
> }
> }{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-12600) Parameters mapping for query parameters to JSON query
[ https://issues.apache.org/jira/browse/SOLR-12600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandre Rafalovitch reassigned SOLR-12600: Assignee: Alexandre Rafalovitch > Parameters mapping for query parameters to JSON query > - > > Key: SOLR-12600 > URL: https://issues.apache.org/jira/browse/SOLR-12600 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Affects Versions: 7.4 >Reporter: Renuka Srishti >Assignee: Alexandre Rafalovitch >Priority: Minor > > Paramters mapping mentioned here is not right. > start, rows works for standard query parameters. > offset, limit works for JSON query. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12600) Parameters mapping for query parameters to JSON query
[ https://issues.apache.org/jira/browse/SOLR-12600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16561127#comment-16561127 ] Alexandre Rafalovitch commented on SOLR-12600: -- Sorry Erick, I said to do it here. The documentation is wrong and needs to be fixed (parameters are swapped). I'll take care of it. > Parameters mapping for query parameters to JSON query > - > > Key: SOLR-12600 > URL: https://issues.apache.org/jira/browse/SOLR-12600 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Affects Versions: 7.4 >Reporter: Renuka Srishti >Priority: Minor > > Paramters mapping mentioned here is not right. > start, rows works for standard query parameters. > offset, limit works for JSON query. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12574) SignificantTermsQParserPlugin should output its keys in a combined bucket
[
https://issues.apache.org/jira/browse/SOLR-12574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandre Rafalovitch updated SOLR-12574:
-
Attachment: (was: SOLR-12574.patch)
> SignificantTermsQParserPlugin should output its keys in a combined bucket
> -
>
> Key: SOLR-12574
> URL: https://issues.apache.org/jira/browse/SOLR-12574
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Affects Versions: 7.4
>Reporter: Alexandre Rafalovitch
>Assignee: Alexandre Rafalovitch
>Priority: Minor
> Attachments: SOLR-12574.patch
>
>
> SignificantTermsQParserPlugin is not yet visible to the users (was not
> documented or spelt correctly in 7.4), so there is still a chance to fix its
> output before people start using it.
> Currently, it injects 6 different keys into the document, on the same level
> as responseHeader and response. This feels like polluting top-level space. It
> may be better to put all those keys under one bucket (e.g. significantTerms).
> Additionally, resultCount is always the same as response.numFound (documents
> found), so does not seem to be needed.
> Current output:
> {code:java}
> {
> "responseHeader": {
> "status": 0,
> "QTime": 1,
> "params": {
> "q": "directed_by_str:\"Steven Soderbergh\"",
> "fq": "{!significantTerms field=genre numTerms=2}",
> "rows": "1",
> "wt": "json"
> }
> },
> "numDocs": 1100,
> "resultCount": 5,
> "sterms": [
> "biographical",
> "romance"
> ],
> "scores": [
> 2.5552773475646973,
> 2.6387078762054443
> ],
> "docFreq": [
> 74,
> 270
> ],
> "queryDocFreq": [
> 2,
> 3
> ],
> "response": {
> "numFound": 5,
> "start": 0,
> "docs": [
> {
> "id": "/en/bubble",
> "directed_by": [
> "Steven Soderbergh"
> ],
> "initial_release_date": "2005-09-03T00:00:00Z",
> "name": "Bubble",
> "genre": [
> "Crime Fiction",
> "Mystery",
> "Indie film",
> "Thriller",
> "Drama"
> ],
> "_version_": 1606610059993808899
> }
> ]
> }
> }{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12574) SignificantTermsQParserPlugin should output its keys in a combined bucket
[
https://issues.apache.org/jira/browse/SOLR-12574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandre Rafalovitch updated SOLR-12574:
-
Attachment: SOLR-12574.patch
> SignificantTermsQParserPlugin should output its keys in a combined bucket
> -
>
> Key: SOLR-12574
> URL: https://issues.apache.org/jira/browse/SOLR-12574
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Affects Versions: 7.4
>Reporter: Alexandre Rafalovitch
>Assignee: Alexandre Rafalovitch
>Priority: Minor
> Attachments: SOLR-12574.patch, SOLR-12574.patch
>
>
> SignificantTermsQParserPlugin is not yet visible to the users (was not
> documented or spelt correctly in 7.4), so there is still a chance to fix its
> output before people start using it.
> Currently, it injects 6 different keys into the document, on the same level
> as responseHeader and response. This feels like polluting top-level space. It
> may be better to put all those keys under one bucket (e.g. significantTerms).
> Additionally, resultCount is always the same as response.numFound (documents
> found), so does not seem to be needed.
> Current output:
> {code:java}
> {
> "responseHeader": {
> "status": 0,
> "QTime": 1,
> "params": {
> "q": "directed_by_str:\"Steven Soderbergh\"",
> "fq": "{!significantTerms field=genre numTerms=2}",
> "rows": "1",
> "wt": "json"
> }
> },
> "numDocs": 1100,
> "resultCount": 5,
> "sterms": [
> "biographical",
> "romance"
> ],
> "scores": [
> 2.5552773475646973,
> 2.6387078762054443
> ],
> "docFreq": [
> 74,
> 270
> ],
> "queryDocFreq": [
> 2,
> 3
> ],
> "response": {
> "numFound": 5,
> "start": 0,
> "docs": [
> {
> "id": "/en/bubble",
> "directed_by": [
> "Steven Soderbergh"
> ],
> "initial_release_date": "2005-09-03T00:00:00Z",
> "name": "Bubble",
> "genre": [
> "Crime Fiction",
> "Mystery",
> "Indie film",
> "Thriller",
> "Drama"
> ],
> "_version_": 1606610059993808899
> }
> ]
> }
> }{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-12574) SignificantTermsQParserPlugin should output its keys in a combined bucket
[
https://issues.apache.org/jira/browse/SOLR-12574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandre Rafalovitch reassigned SOLR-12574:
Assignee: Alexandre Rafalovitch
Attachment: SOLR-12574.patch
Patch grouping all keys under common parents and removing redundant resultCount.
> SignificantTermsQParserPlugin should output its keys in a combined bucket
> -
>
> Key: SOLR-12574
> URL: https://issues.apache.org/jira/browse/SOLR-12574
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Affects Versions: 7.4
>Reporter: Alexandre Rafalovitch
>Assignee: Alexandre Rafalovitch
>Priority: Minor
> Attachments: SOLR-12574.patch
>
>
> SignificantTermsQParserPlugin is not yet visible to the users (was not
> documented or spelt correctly in 7.4), so there is still a chance to fix its
> output before people start using it.
> Currently, it injects 6 different keys into the document, on the same level
> as responseHeader and response. This feels like polluting top-level space. It
> may be better to put all those keys under one bucket (e.g. significantTerms).
> Additionally, resultCount is always the same as response.numFound (documents
> found), so does not seem to be needed.
> Current output:
> {code:java}
> {
> "responseHeader": {
> "status": 0,
> "QTime": 1,
> "params": {
> "q": "directed_by_str:\"Steven Soderbergh\"",
> "fq": "{!significantTerms field=genre numTerms=2}",
> "rows": "1",
> "wt": "json"
> }
> },
> "numDocs": 1100,
> "resultCount": 5,
> "sterms": [
> "biographical",
> "romance"
> ],
> "scores": [
> 2.5552773475646973,
> 2.6387078762054443
> ],
> "docFreq": [
> 74,
> 270
> ],
> "queryDocFreq": [
> 2,
> 3
> ],
> "response": {
> "numFound": 5,
> "start": 0,
> "docs": [
> {
> "id": "/en/bubble",
> "directed_by": [
> "Steven Soderbergh"
> ],
> "initial_release_date": "2005-09-03T00:00:00Z",
> "name": "Bubble",
> "genre": [
> "Crime Fiction",
> "Mystery",
> "Indie film",
> "Thriller",
> "Drama"
> ],
> "_version_": 1606610059993808899
> }
> ]
> }
> }{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12494) Migration documentation
[ https://issues.apache.org/jira/browse/SOLR-12494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16559986#comment-16559986 ] Alexandre Rafalovitch commented on SOLR-12494: -- Hi Ana, This case has been closed as Invalid. You were advised to use the mailing list. Yes, sometimes people do not see enough details in your email and not sure how to answer. But this would be even less the case with the JIRAs, as they are not designed for this (for Apache projects). Could you please ask again at the Solr Users mailing list and try to be as precise as possible with your setup/issues, including specific version of Solr. > Migration documentation > > > Key: SOLR-12494 > URL: https://issues.apache.org/jira/browse/SOLR-12494 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Affects Versions: 6.4.2 > Environment: Stage >Reporter: Ana >Priority: Trivial > > I have the following scenario, I'm having a shared cluster solr installation > environment (app server 1-app server 2 load balanced) which has 4 solr > instances. > > After reviewing the space audit we have noticed that the partition where the > installation resides is too big versus what is used in term of space. > > Therefore we have installed a new drive which is smaller and now we want to > migrate from the old dive (E:) to the new drive (F). > > Can you please provide an official answer whether this is a supported > scenario? > > If yes, will you please share the steps with us? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10299) Provide search for online Ref Guide
[ https://issues.apache.org/jira/browse/SOLR-10299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16559984#comment-16559984 ] Alexandre Rafalovitch commented on SOLR-10299: -- It took a bit of head-scratching to realize that the options will appear on hitting the enter as opposed to the current auto-complete. More importantly, there is no feedback to evaluate the search by. It does seem to pick-up titles and text keywords much better than current implementation. It _seems_ to give boost to the titles over plain text. Maybe one thing I would add is which section the text is found in by splitting the page document into parent/child arrangement during indexing. We do have a lot of multi-topic pages. And then jump to the right page section from the screen. And/or highlighting matching text. > Provide search for online Ref Guide > --- > > Key: SOLR-10299 > URL: https://issues.apache.org/jira/browse/SOLR-10299 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Cassandra Targett >Priority: Major > Attachments: basic-services-diagram.png > > > The POC to move the Ref Guide off Confluence did not address providing > full-text search of the page content. Not because it's hard or impossible, > but because there were plenty of other issues to work on. > The current HTML page design provides a title index, but to replicate the > current Confluence experience, the online version(s) need to provide a > full-text search experience. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-10042) Delete old deprecated Admin UI
[ https://issues.apache.org/jira/browse/SOLR-10042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandre Rafalovitch closed SOLR-10042. > Delete old deprecated Admin UI > -- > > Key: SOLR-10042 > URL: https://issues.apache.org/jira/browse/SOLR-10042 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Fix For: 7.0 > > Attachments: SOLR-10042.patch, SOLR-10042_remove_commented.patch > > > The old jQuery based Admin UI has been deprecated since 6.0. Let us clean up > the last known bugs in Angular UI and simply delete the old UI in master. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16555887#comment-16555887 ] Alexandre Rafalovitch commented on LUCENE-2562: --- Couple of points to consider: * JDK 11 is a disruption moment anyway, as Oracle will no longer provide the official JDK to non-paying customers. Instead, there will be (Redhat-like) policy of OpenJDK vs Official JDK: [http://www.oracle.com/technetwork/java/javase/eol-135779.html] So, we would have to have some real thinking/testing around what that means. * If Luke is supposed to be part of Solr distribution, we already have HTML/CSS assets for Admin UI, etc. Luke could potentially be a plugin of sorts (which has its own issues too) * If Luke is supposed to be part of Lucene-only distribution, I guess the discussion is a bit more complicated > Make Luke a Lucene/Solr Module > -- > > Key: LUCENE-2562 > URL: https://issues.apache.org/jira/browse/LUCENE-2562 > Project: Lucene - Core > Issue Type: Task >Reporter: Mark Miller >Priority: Major > Labels: gsoc2014 > Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, > LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, > LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, > Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png, > luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png > > Time Spent: 10m > Remaining Estimate: 0h > > see > "RE: Luke - in need of maintainer": > http://markmail.org/message/m4gsto7giltvrpuf > "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q > I think it would be great if there was a version of Luke that always worked > with trunk - and it would also be great if it was easier to match Luke jars > with Lucene versions. > While I'd like to get GWT Luke into the mix as well, I think the easiest > starting point is to straight port Luke to another UI toolkit before > abstracting out DTO objects that both GWT Luke and Pivot Luke could share. > I've started slowly converting Luke's use of thinlet to Apache Pivot. I > haven't/don't have a lot of time for this at the moment, but I've plugged > away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12581) add a "min_popularity" option to relatedness() aggregation that forces scores to -Inf if fg/bg pops don't meet a threshold
[
https://issues.apache.org/jira/browse/SOLR-12581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16553241#comment-16553241
]
Alexandre Rafalovitch commented on SOLR-12581:
--
Sort of a side-question, but this work seems to overlap/compliment the
significantTerms work done for streaming/QueryParser:
[http://lucene.apache.org/solr/guide/7_4/stream-source-reference.html#significantterms]
Are we saying SignificantTerms is for simpler use cases (as fore/back queries
are corpus-wide) and then go into relatedness() for more complex analysis?
Should the options be roughly compatible where it makes sense and/or similarly
named?
Just wondering because I could see this confusing newbies trying to see when to
use which option.
> add a "min_popularity" option to relatedness() aggregation that forces scores
> to -Inf if fg/bg pops don't meet a threshold
> --
>
> Key: SOLR-12581
> URL: https://issues.apache.org/jira/browse/SOLR-12581
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-12581.patch
>
>
> as discussed in SOLR-9480 and noted in TODO comments, the original SKG code
> base had a "min_pop" option that would completely ignore "terms" if the fg/bg
> popularities weren't above a user specified threshold. with the
> implementation of SKG as a {{relatedness()}} aggregation function, we need to
> leave any actual filtering of buckets by an aggregation result to a future
> generalized JSON facet enhancement, but what we can do today is implement an
> optional {{min_popularity}} option on {{relatedness()}} that forces the
> {{relatedness}} score to -Infinity so buckets that don't meat the threshold
> at least score "as low as possible"
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12580) Ref Guide should include English-specific information in the Language Analysis page
Alexandre Rafalovitch created SOLR-12580: Summary: Ref Guide should include English-specific information in the Language Analysis page Key: SOLR-12580 URL: https://issues.apache.org/jira/browse/SOLR-12580 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: documentation Affects Versions: 7.4 Reporter: Alexandre Rafalovitch Solr Reference guide [page on Language Analysis|http://lucene.apache.org/solr/guide/7_4/language-analysis.html] has specific information for multiple languages, but not for English. While it is obvious that Solr supports English, it would still be useful to point to the different ways it can do it (similar to what we do for other languages). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12574) SignificantTermsQParserPlugin should output its keys in a combined bucket
Alexandre Rafalovitch created SOLR-12574:
Summary: SignificantTermsQParserPlugin should output its keys in a
combined bucket
Key: SOLR-12574
URL: https://issues.apache.org/jira/browse/SOLR-12574
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Components: query parsers
Affects Versions: 7.4
Reporter: Alexandre Rafalovitch
SignificantTermsQParserPlugin is not yet visible to the users (was not
documented or spelt correctly in 7.4), so there is still a chance to fix its
output before people start using it.
Currently, it injects 6 different keys into the document, on the same level as
responseHeader and response. This feels like polluting top-level space. It may
be better to put all those keys under one bucket (e.g. significantTerms).
Additionally, resultCount is always the same as response.numFound (documents
found), so does not seem to be needed.
Current output:
{code:java}
{
"responseHeader": {
"status": 0,
"QTime": 1,
"params": {
"q": "directed_by_str:\"Steven Soderbergh\"",
"fq": "{!significantTerms field=genre numTerms=2}",
"rows": "1",
"wt": "json"
}
},
"numDocs": 1100,
"resultCount": 5,
"sterms": [
"biographical",
"romance"
],
"scores": [
2.5552773475646973,
2.6387078762054443
],
"docFreq": [
74,
270
],
"queryDocFreq": [
2,
3
],
"response": {
"numFound": 5,
"start": 0,
"docs": [
{
"id": "/en/bubble",
"directed_by": [
"Steven Soderbergh"
],
"initial_release_date": "2005-09-03T00:00:00Z",
"name": "Bubble",
"genre": [
"Crime Fiction",
"Mystery",
"Indie film",
"Thriller",
"Drama"
],
"_version_": 1606610059993808899
}
]
}
}{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-12569) Document SignificantTermsQParserPlugin
[ https://issues.apache.org/jira/browse/SOLR-12569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandre Rafalovitch reassigned SOLR-12569: Assignee: Alexandre Rafalovitch > Document SignificantTermsQParserPlugin > -- > > Key: SOLR-12569 > URL: https://issues.apache.org/jira/browse/SOLR-12569 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Alexandre Rafalovitch >Assignee: Alexandre Rafalovitch >Priority: Major > > SignificantTermsQParserPlugin was introduced at the same as significantTerms > stream source, but only the stream source was documented. > QParser should be documented too, especially since it can be used in > non-cloud mode and has to be used as fq (otherwise, it throws exception). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12569) Document SignificantTermsQParserPlugin
Alexandre Rafalovitch created SOLR-12569: Summary: Document SignificantTermsQParserPlugin Key: SOLR-12569 URL: https://issues.apache.org/jira/browse/SOLR-12569 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: documentation Reporter: Alexandre Rafalovitch SignificantTermsQParserPlugin was introduced at the same as significantTerms stream source, but only the stream source was documented. QParser should be documented too, especially since it can be used in non-cloud mode and has to be used as fq (otherwise, it throws exception). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-12553) SignificantTermsQParserPlugin ignores local params
[ https://issues.apache.org/jira/browse/SOLR-12553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandre Rafalovitch resolved SOLR-12553. -- Resolution: Resolved Fix Version/s: 7.5 getParam did not actually have a version that supported defaults. So, for now, I've added this 3-line code in this file only. Does not seem like there is a lot of demand for it in other places. > SignificantTermsQParserPlugin ignores local params > -- > > Key: SOLR-12553 > URL: https://issues.apache.org/jira/browse/SOLR-12553 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: query parsers >Affects Versions: 7.4 >Reporter: Alexandre Rafalovitch >Assignee: Alexandre Rafalovitch >Priority: Major > Fix For: 7.5 > > Attachments: SOLR-12553.patch > > > _SignificantTermsQParserPlugin_ can take a number of parameters (field, > numTerms, minTermLength, etc). However, only _field_ parameter can be local > or global. The rest of parameters can only be global, which does not make > sense. > The fix is to use _getParam()_ method consistently when getting the > parameters. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8409) Cannot delete individual fields from index
[ https://issues.apache.org/jira/browse/LUCENE-8409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16547319#comment-16547319 ] Alexandre Rafalovitch commented on LUCENE-8409: --- I seem to remember the discussion about doing segment-by-segment rewrite with some sort of filtered reader that would clear the remove fields in process. But I cannot find the discussion of whether it was fully relevant. But yes I agree that it is quite problematic in terms of index evolution. > Cannot delete individual fields from index > -- > > Key: LUCENE-8409 > URL: https://issues.apache.org/jira/browse/LUCENE-8409 > Project: Lucene - Core > Issue Type: Bug >Reporter: Cetra Free >Priority: Major > > This is based upon the following tickets: > https://issues.apache.org/jira/browse/SOLR-12185 > https://issues.apache.org/jira/browse/LUCENE-8235 > I'd like a way to be able to clear and recreate a specific field so I don't > have to completely reindex if I change a field type. > It's a real pain if you change a specific field from single valued to > multivalued, you have to delete the entire index from disk and start from > scratch. > As being able to modify a field is not an [intended > feature|https://issues.apache.org/jira/browse/LUCENE-8235?focusedCommentId=16530918=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16530918], > It'd be preferable if a field could be at least deleted and recreated to > deal with this scenario. > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-12553) SignificantTermsQParserPlugin ignores local params
[ https://issues.apache.org/jira/browse/SOLR-12553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandre Rafalovitch reassigned SOLR-12553: Assignee: Alexandre Rafalovitch Attachment: SOLR-12553.patch [~joel.bernstein] Does this make sense as a problem and the fix? Also, I could not find any documentation for the Query Parser, I guess we need a separate Jira for that. > SignificantTermsQParserPlugin ignores local params > -- > > Key: SOLR-12553 > URL: https://issues.apache.org/jira/browse/SOLR-12553 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: query parsers >Affects Versions: 7.4 >Reporter: Alexandre Rafalovitch >Assignee: Alexandre Rafalovitch >Priority: Major > Attachments: SOLR-12553.patch > > > _SignificantTermsQParserPlugin_ can take a number of parameters (field, > numTerms, minTermLength, etc). However, only _field_ parameter can be local > or global. The rest of parameters can only be global, which does not make > sense. > The fix is to use _getParam()_ method consistently when getting the > parameters. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12553) SignificantTermsQParserPlugin ignores local params
Alexandre Rafalovitch created SOLR-12553: Summary: SignificantTermsQParserPlugin ignores local params Key: SOLR-12553 URL: https://issues.apache.org/jira/browse/SOLR-12553 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Components: query parsers Affects Versions: 7.4 Reporter: Alexandre Rafalovitch _SignificantTermsQParserPlugin_ can take a number of parameters (field, numTerms, minTermLength, etc). However, only _field_ parameter can be local or global. The rest of parameters can only be global, which does not make sense. The fix is to use _getParam()_ method consistently when getting the parameters. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
