[Lucene.Net] who is our current PMC
Who is our current PMC? I feel stupid for asking, but I can't find it on the wiki, site, etc. I need to get a build account and get all the fun CI stuff setup. - michael
Re: [Lucene.Net] who is our current PMC
On 2011-09-17, Michael Herndon wrote: Who is our current PMC? The Incubator PMC. Stefan
Re: [Lucene.Net] who is our current PMC
On 2011-09-18, Michael Herndon wrote: So would requesting getting an account be requested on lucene-net-private@ incubator.apache.org ? Creating the account requires PMC chairman karma, which I happen to posess. I've just added you to the hudson-jobadmin group. I don't see any place that mentions a private mailing list on the Wiki page at all, so I assume you were looking for the PMC chairman to help out. Well, that would have been private at incubator. Do you need me to do anything more (I'm not familiar with our Jenkins setup at all)? Stefan
IOException ignoring in QueryParserBase
As part of moving over to mandatory reusable Analyzers, I'm confronting how best to handle the IOException thrown by reusableTokenStream. One piece of code thats frustrating me is QueryParserBase.newFieldQuery where I notice that at any stage if an IOException is thrown, its simply ignored. Does anyone known why we do this? Do we want to continue with this approach? Solr's TextField.parseFieldQuery, which is basically a CP of the code from newFieldQuery, has the same issues. Cheers Chris -- Chris Male | Software Developer | JTeam BV.| www.jteam.nl
[jira] [Commented] (SOLR-2762) FSTLookup returns one less suggestion than it should when onlyMorePopular=true
[ https://issues.apache.org/jira/browse/SOLR-2762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107050#comment-13107050 ] Dawid Weiss commented on SOLR-2762: --- Ugh... David, you're a machine (5:20am). No, I wasn't teasing, I was really done for the day yesterday. I will commit today, thanks for your help again! FSTLookup returns one less suggestion than it should when onlyMorePopular=true -- Key: SOLR-2762 URL: https://issues.apache.org/jira/browse/SOLR-2762 Project: Solr Issue Type: Bug Components: spellchecker Affects Versions: 3.3 Reporter: David Smiley Assignee: Dawid Weiss Priority: Minor Attachments: SOLR-2762.patch, SOLR-2762.patch, SOLR-2762.patch, SOLR-2762_FSTLookup_off_by_one.patch, SOLR-2762_FSTLookup_off_by_one.patch I'm using the Suggester. When I switched from TSTLookup to FSTLookup, I noticed that it returned one fewer suggestion than what I asked for. I have spellcheck.onlyMorePopular=true; when I set it to false, I see the correct count. Another aspect of the bug is that this off-by-one bug only seems to occur when my suggestion has an exact match. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1395) Integrate Katta
[ https://issues.apache.org/jira/browse/SOLR-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107053#comment-13107053 ] JohnWu commented on SOLR-1395: -- Tom: 1) yes, the code is update the index with segment style, that's great,but it can not sync index when one node crash down. So I create index with renew the whole index. 2) still for the facet issue, can you give me a case about facet? tell me the detail steps, someone told me the facet data is stored in the front end, so it can not get the global info for our distributed system. thanks! JohnWu Integrate Katta --- Key: SOLR-1395 URL: https://issues.apache.org/jira/browse/SOLR-1395 Project: Solr Issue Type: New Feature Affects Versions: 1.4 Reporter: Jason Rutherglen Priority: Minor Fix For: 3.5, 4.0 Attachments: SOLR-1395.patch, SOLR-1395.patch, SOLR-1395.patch, back-end.log, front-end.log, hadoop-core-0.19.0.jar, katta-core-0.6-dev.jar, katta-solrcores.jpg, katta.node.properties, katta.zk.properties, log4j-1.2.13.jar, solr-1395-1431-3.patch, solr-1395-1431-4.patch, solr-1395-1431-katta0.6.patch, solr-1395-1431-katta0.6.patch, solr-1395-1431.patch, solr-1395-katta-0.6.2-1.patch, solr-1395-katta-0.6.2-2.patch, solr-1395-katta-0.6.2-3.patch, solr-1395-katta-0.6.2.patch, solr-1395-katta-0.6.3-4.patch, solr1395.jpg, test-katta-core-0.6-dev.jar, zkclient-0.1-dev.jar, zookeeper-3.2.1.jar Original Estimate: 336h Remaining Estimate: 336h We'll integrate Katta into Solr so that: * Distributed search uses Hadoop RPC * Shard/SolrCore distribution and management * Zookeeper based failover * Indexes may be built using Hadoop -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2754) create Solr similarity factories for new ranking algorithms
[ https://issues.apache.org/jira/browse/SOLR-2754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107069#comment-13107069 ] David Mark Nemeskey commented on SOLR-2754: --- bq. Well, we can do both: we can provide these basic parameters as default values to be friendly, but at the same time in the test or example xml configurations that use these, our examples can have the parameters set. That's a good idea. I could modify the patch if you want to, and also break the long lines into two in the meantime. create Solr similarity factories for new ranking algorithms --- Key: SOLR-2754 URL: https://issues.apache.org/jira/browse/SOLR-2754 Project: Solr Issue Type: New Feature Affects Versions: 4.0 Reporter: Robert Muir Assignee: Robert Muir Attachments: SOLR-2754.patch To make it easy to use some of the new ranking algorithms, we should add factories to solr: * for parametric models like LM and BM25 so that parameters can be set from schema.xml * for framework models like DFR and IB, so that different basic models/normalizations/lambdas can be chosen -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2215) paging collector
[ https://issues.apache.org/jira/browse/LUCENE-2215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107103#comment-13107103 ] Michael McCandless commented on LUCENE-2215: +1 for TopDocs searchAfter(ScoreDoc previous, Query query, int n), though maybe name the param after not previous? paging collector Key: LUCENE-2215 URL: https://issues.apache.org/jira/browse/LUCENE-2215 Project: Lucene - Java Issue Type: New Feature Components: core/search Affects Versions: 2.4, 3.0 Reporter: Adam Heinz Assignee: Grant Ingersoll Priority: Minor Attachments: IterablePaging.java, LUCENE-2215.patch, LUCENE-2215.patch, PagingCollector.java, TestingPagingCollector.java http://issues.apache.org/jira/browse/LUCENE-2127?focusedCommentId=12796898page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12796898 Somebody assign this to Aaron McCurry and we'll see if we can get enough votes on this issue to convince him to upload his patch. :) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-2066) Search Grouping: support distributed search
[ https://issues.apache.org/jira/browse/SOLR-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn van Groningen resolved SOLR-2066. - Resolution: Fixed Committed. trunk: 1171970 3x branch: 1171968 Search Grouping: support distributed search --- Key: SOLR-2066 URL: https://issues.apache.org/jira/browse/SOLR-2066 Project: Solr Issue Type: Sub-task Reporter: Yonik Seeley Fix For: 3.5, 4.0 Attachments: SOLR-2066-3x.patch, SOLR-2066.patch, SOLR-2066.patch, SOLR-2066.patch, SOLR-2066.patch, SOLR-2066.patch, SOLR-2066.patch, SOLR-2066.patch, SOLR-2066.patch, SOLR-2066.patch, SOLR-2066.patch, SOLR-2066.patch, SOLR-2066.patch, SOLR-2066.patch Support distributed field collapsing / search grouping. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-2776) Support group.truncate for distributed grouping
Support group.truncate for distributed grouping --- Key: SOLR-2776 URL: https://issues.apache.org/jira/browse/SOLR-2776 Project: Solr Issue Type: Improvement Reporter: Martijn van Groningen Assignee: Martijn van Groningen Fix For: 3.5, 4.0 Currently group.truncate isn't supported when executing a distributed grouped search. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-2777) Support group.func for distributed grouping
Support group.func for distributed grouping --- Key: SOLR-2777 URL: https://issues.apache.org/jira/browse/SOLR-2777 Project: Solr Issue Type: Improvement Reporter: Martijn van Groningen Fix For: 4.0 Support group.func for distributed grouping. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-2777) Support group.func for distributed grouping
[ https://issues.apache.org/jira/browse/SOLR-2777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn van Groningen reassigned SOLR-2777: --- Assignee: Martijn van Groningen Support group.func for distributed grouping --- Key: SOLR-2777 URL: https://issues.apache.org/jira/browse/SOLR-2777 Project: Solr Issue Type: Improvement Reporter: Martijn van Groningen Assignee: Martijn van Groningen Fix For: 4.0 Support group.func for distributed grouping. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2754) create Solr similarity factories for new ranking algorithms
[ https://issues.apache.org/jira/browse/SOLR-2754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107116#comment-13107116 ] Robert Muir commented on SOLR-2754: --- +1 create Solr similarity factories for new ranking algorithms --- Key: SOLR-2754 URL: https://issues.apache.org/jira/browse/SOLR-2754 Project: Solr Issue Type: New Feature Affects Versions: 4.0 Reporter: Robert Muir Assignee: Robert Muir Attachments: SOLR-2754.patch To make it easy to use some of the new ranking algorithms, we should add factories to solr: * for parametric models like LM and BM25 so that parameters can be set from schema.xml * for framework models like DFR and IB, so that different basic models/normalizations/lambdas can be chosen -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-2778) Revise distributed code inside SearchComponents
Revise distributed code inside SearchComponents --- Key: SOLR-2778 URL: https://issues.apache.org/jira/browse/SOLR-2778 Project: Solr Issue Type: Improvement Reporter: Martijn van Groningen The distributed code inside search components such as QueryComponent and FacetComponent is complex. By structuring responsibilities the code becomes less complex and easier to understand. There is already a start for this that was part of distributed grouping (SOLR-2066). The following concepts were developed inside QueryComponent for SOLR-2066: * ShardRequestFactory is responsible for creating requests to shards in the cluster based on the incoming request from the client. * ShardResultTransformer. Transforming a NamedList response from the client in for example SearchGroup or TopDocs instance. * ShardResponseProcessor. Basically merges the shard responses. The ShardReponseProcessor uses a ShardResultTransformer to transform the shard response into a native structure (SearchGroup / TopGroups). These concepts are now only used for distributed grouping, but I think can also be used for non grouped distributed search. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-1895) ManifoldCF SearchComponent plugin for enforcing ManifoldCF security at search time
[
https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koji Sekiguchi updated SOLR-1895:
-
Attachment: SOLR-1895.patch
Ok, I moved it to core in this patch.
I added test code, but the following test doesn't pass (I cannot understand
why):
{code}
@Test
public void testUserTokens() throws Exception {
/* this test doesn't work...???
assertQ(req(qt, /mcf, q, *:*, fl, id, UserTokens, token2),
//*[@numFound='4'],
//result/doc[1]/str[@name='id'][.='d-a12'],
//result/doc[2]/str[@name='id'][.='s-d13'],
//result/doc[3]/str[@name='id'][.='ds-a23-d1'],
//result/doc[4]/str[@name='id'][.='notoken']);
*/
/* this test doesn't work...???
assertQ(req(qt, /mcf, q, *:*, fl, id, UserTokens, token3),
//*[@numFound='2'],
//result/doc[1]/str[@name='id'][.='ds-a23-d1'],
//result/doc[2]/str[@name='id'][.='notoken']);
*/
:
}
{code}
In this patch, I also did:
- remove unused import
- fix indent
- use Java5 for loop
- move Security param (in NamedList) to mcf param (in request parameter
resolved at runtime)
- check isShard param at the beginning of prepare() to support distributed
search
- remove redundant ManifoldCFSecurityFilter in log messages
- add the filter to example
- get socket time out parameter from solrconfig.xml
ManifoldCF SearchComponent plugin for enforcing ManifoldCF security at search
time
--
Key: SOLR-1895
URL: https://issues.apache.org/jira/browse/SOLR-1895
Project: Solr
Issue Type: New Feature
Components: SearchComponents - other
Reporter: Karl Wright
Labels: document, security, solr
Fix For: 3.5, 4.0
Attachments: LCFSecurityFilter.java, LCFSecurityFilter.java,
LCFSecurityFilter.java, LCFSecurityFilter.java, SOLR-1895.patch,
SOLR-1895.patch
I've written an LCF SearchComponent which filters returned results based on
access tokens provided by LCF's authority service. The component requires
you to configure the appropriate authority service URL base, e.g.:
!-- LCF document security enforcement component --
searchComponent name=lcfSecurity class=LCFSecurityFilter
str
name=AuthorityServiceBaseURLhttp://localhost:8080/lcf-authority-service/str
/searchComponent
Also required are the following schema.xml additions:
!-- Security fields --
field name=allow_token_document type=string indexed=true
stored=false multiValued=true/
field name=deny_token_document type=string indexed=true
stored=false multiValued=true/
field name=allow_token_share type=string indexed=true
stored=false multiValued=true/
field name=deny_token_share type=string indexed=true stored=false
multiValued=true/
Finally, to tie it into the standard request handler, it seems to need to run
last:
requestHandler name=standard class=solr.SearchHandler default=true
arr name=last-components
strlcfSecurity/str
/arr
...
I have not set a package for this code. Nor have I been able to get it
reviewed by someone as conversant with Solr as I would prefer. It is my
hope, however, that this module will become part of the standard Solr 1.5
suite of search components, since that would tie it in with LCF nicely.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1895) ManifoldCF SearchComponent plugin for enforcing ManifoldCF security at search time
[
https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107143#comment-13107143
]
Koji Sekiguchi commented on SOLR-1895:
--
{quote}
I'll post an updated version that does everything except the caching. My
reasoning is that this can be readily added should it prove beneficial. I would
want to show that it was helpful before adding the extra configuration
complexity.
{quote}
I agree. Let's open another issue once this is done.
ManifoldCF SearchComponent plugin for enforcing ManifoldCF security at search
time
--
Key: SOLR-1895
URL: https://issues.apache.org/jira/browse/SOLR-1895
Project: Solr
Issue Type: New Feature
Components: SearchComponents - other
Reporter: Karl Wright
Labels: document, security, solr
Fix For: 3.5, 4.0
Attachments: LCFSecurityFilter.java, LCFSecurityFilter.java,
LCFSecurityFilter.java, LCFSecurityFilter.java, SOLR-1895.patch,
SOLR-1895.patch
I've written an LCF SearchComponent which filters returned results based on
access tokens provided by LCF's authority service. The component requires
you to configure the appropriate authority service URL base, e.g.:
!-- LCF document security enforcement component --
searchComponent name=lcfSecurity class=LCFSecurityFilter
str
name=AuthorityServiceBaseURLhttp://localhost:8080/lcf-authority-service/str
/searchComponent
Also required are the following schema.xml additions:
!-- Security fields --
field name=allow_token_document type=string indexed=true
stored=false multiValued=true/
field name=deny_token_document type=string indexed=true
stored=false multiValued=true/
field name=allow_token_share type=string indexed=true
stored=false multiValued=true/
field name=deny_token_share type=string indexed=true stored=false
multiValued=true/
Finally, to tie it into the standard request handler, it seems to need to run
last:
requestHandler name=standard class=solr.SearchHandler default=true
arr name=last-components
strlcfSecurity/str
/arr
...
I have not set a package for this code. Nor have I been able to get it
reviewed by someone as conversant with Solr as I would prefer. It is my
hope, however, that this module will become part of the standard Solr 1.5
suite of search components, since that would tie it in with LCF nicely.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1895) ManifoldCF SearchComponent plugin for enforcing ManifoldCF security at search time
[ https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107144#comment-13107144 ] Koji Sekiguchi commented on SOLR-1895: -- I forgot that I have a question. Can we remove globalAllowed? ManifoldCF SearchComponent plugin for enforcing ManifoldCF security at search time -- Key: SOLR-1895 URL: https://issues.apache.org/jira/browse/SOLR-1895 Project: Solr Issue Type: New Feature Components: SearchComponents - other Reporter: Karl Wright Labels: document, security, solr Fix For: 3.5, 4.0 Attachments: LCFSecurityFilter.java, LCFSecurityFilter.java, LCFSecurityFilter.java, LCFSecurityFilter.java, SOLR-1895.patch, SOLR-1895.patch I've written an LCF SearchComponent which filters returned results based on access tokens provided by LCF's authority service. The component requires you to configure the appropriate authority service URL base, e.g.: !-- LCF document security enforcement component -- searchComponent name=lcfSecurity class=LCFSecurityFilter str name=AuthorityServiceBaseURLhttp://localhost:8080/lcf-authority-service/str /searchComponent Also required are the following schema.xml additions: !-- Security fields -- field name=allow_token_document type=string indexed=true stored=false multiValued=true/ field name=deny_token_document type=string indexed=true stored=false multiValued=true/ field name=allow_token_share type=string indexed=true stored=false multiValued=true/ field name=deny_token_share type=string indexed=true stored=false multiValued=true/ Finally, to tie it into the standard request handler, it seems to need to run last: requestHandler name=standard class=solr.SearchHandler default=true arr name=last-components strlcfSecurity/str /arr ... I have not set a package for this code. Nor have I been able to get it reviewed by someone as conversant with Solr as I would prefer. It is my hope, however, that this module will become part of the standard Solr 1.5 suite of search components, since that would tie it in with LCF nicely. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-2215) paging collector
[ https://issues.apache.org/jira/browse/LUCENE-2215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-2215: Attachment: LUCENE-2215.patch renamed to searchAfter, added a little to the javadocs, and improved the test coverage a bit. paging collector Key: LUCENE-2215 URL: https://issues.apache.org/jira/browse/LUCENE-2215 Project: Lucene - Java Issue Type: New Feature Components: core/search Affects Versions: 2.4, 3.0 Reporter: Adam Heinz Assignee: Grant Ingersoll Priority: Minor Attachments: IterablePaging.java, LUCENE-2215.patch, LUCENE-2215.patch, LUCENE-2215.patch, PagingCollector.java, TestingPagingCollector.java http://issues.apache.org/jira/browse/LUCENE-2127?focusedCommentId=12796898page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12796898 Somebody assign this to Aaron McCurry and we'll see if we can get enough votes on this issue to convince him to upload his patch. :) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-2762) FSTLookup returns one less suggestion than it should when onlyMorePopular=true
[ https://issues.apache.org/jira/browse/SOLR-2762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss resolved SOLR-2762. --- Resolution: Fixed Fix Version/s: 3.5 FSTLookup returns one less suggestion than it should when onlyMorePopular=true -- Key: SOLR-2762 URL: https://issues.apache.org/jira/browse/SOLR-2762 Project: Solr Issue Type: Bug Components: spellchecker Affects Versions: 3.3, 3.4 Reporter: David Smiley Assignee: Dawid Weiss Priority: Minor Fix For: 3.5 Attachments: SOLR-2762.patch, SOLR-2762.patch, SOLR-2762.patch, SOLR-2762_FSTLookup_off_by_one.patch, SOLR-2762_FSTLookup_off_by_one.patch I'm using the Suggester. When I switched from TSTLookup to FSTLookup, I noticed that it returned one fewer suggestion than what I asked for. I have spellcheck.onlyMorePopular=true; when I set it to false, I see the correct count. Another aspect of the bug is that this off-by-one bug only seems to occur when my suggestion has an exact match. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2762) FSTLookup returns one less suggestion than it should when onlyMorePopular=true
[ https://issues.apache.org/jira/browse/SOLR-2762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss updated SOLR-2762: -- Affects Version/s: 3.4 FSTLookup returns one less suggestion than it should when onlyMorePopular=true -- Key: SOLR-2762 URL: https://issues.apache.org/jira/browse/SOLR-2762 Project: Solr Issue Type: Bug Components: spellchecker Affects Versions: 3.3, 3.4 Reporter: David Smiley Assignee: Dawid Weiss Priority: Minor Fix For: 3.5 Attachments: SOLR-2762.patch, SOLR-2762.patch, SOLR-2762.patch, SOLR-2762_FSTLookup_off_by_one.patch, SOLR-2762_FSTLookup_off_by_one.patch I'm using the Suggester. When I switched from TSTLookup to FSTLookup, I noticed that it returned one fewer suggestion than what I asked for. I have spellcheck.onlyMorePopular=true; when I set it to false, I see the correct count. Another aspect of the bug is that this off-by-one bug only seems to occur when my suggestion has an exact match. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: svn commit: r1172011 - in /lucene/dev/branches/branch_3x: lucene/ lucene/contrib/spellchecker/src/java/org/apache/lucene/search/suggest/fst/ lucene/contrib/spellchecker/src/test/org/apache/lucene/
I was wondering where to place this in CHANGES files -- the issue is marked SOLR in Jira, but is in a module on 4.x line... and in the 3.x line it is part of Lucene. Any hints how to do it consistently or better? Dawid == --- lucene/dev/branches/branch_3x/lucene/CHANGES.txt (original) +++ lucene/dev/branches/branch_3x/lucene/CHANGES.txt Sat Sep 17 16:26:43 2011 @@ -7,6 +7,9 @@ http://s.apache.org/luceneversions Bug fixes +* SOLR-2762: (backport form 4.x line): FSTLookup could return duplicate + results or one results less than requested. (David Smiley, Dawid Weiss) + * LUCENE-3412: SloppyPhraseScorer was returning non-deterministic results - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
trunk test failure (1316275321)
A test failure occurred running the tests. revert! revert! revert! You can see the entire build log at http://sierranevada.servebeer.com/1316275321.log Thanks, Charlie Cron - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: svn commit: r1172011 - in /lucene/dev/branches/branch_3x: lucene/ lucene/contrib/spellchecker/src/java/org/apache/lucene/search/suggest/fst/ lucene/contrib/spellchecker/src/test/org/apache/lucene/
i'd put it where the code is in 3.x, since thats the version where the change will appear? On Sat, Sep 17, 2011 at 12:30 PM, Dawid Weiss dwe...@apache.org wrote: I was wondering where to place this in CHANGES files -- the issue is marked SOLR in Jira, but is in a module on 4.x line... and in the 3.x line it is part of Lucene. Any hints how to do it consistently or better? Dawid == --- lucene/dev/branches/branch_3x/lucene/CHANGES.txt (original) +++ lucene/dev/branches/branch_3x/lucene/CHANGES.txt Sat Sep 17 16:26:43 2011 @@ -7,6 +7,9 @@ http://s.apache.org/luceneversions Bug fixes +* SOLR-2762: (backport form 4.x line): FSTLookup could return duplicate + results or one results less than requested. (David Smiley, Dawid Weiss) + * LUCENE-3412: SloppyPhraseScorer was returning non-deterministic results - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: svn commit: r1172011 - in /lucene/dev/branches/branch_3x: lucene/ lucene/contrib/spellchecker/src/java/org/apache/lucene/search/suggest/fst/ lucene/contrib/spellchecker/src/test/org/apache/lucene/
You mean -- put it under lucene/CHANGES on both dev. lines? It does make sense to place it in SOLR's file too though because it affects Solr's functionality... Darn. I think I'll just leave it the way it's already done. Dawid On Sat, Sep 17, 2011 at 6:52 PM, Robert Muir rcm...@gmail.com wrote: i'd put it where the code is in 3.x, since thats the version where the change will appear? On Sat, Sep 17, 2011 at 12:30 PM, Dawid Weiss dwe...@apache.org wrote: I was wondering where to place this in CHANGES files -- the issue is marked SOLR in Jira, but is in a module on 4.x line... and in the 3.x line it is part of Lucene. Any hints how to do it consistently or better? Dawid == --- lucene/dev/branches/branch_3x/lucene/CHANGES.txt (original) +++ lucene/dev/branches/branch_3x/lucene/CHANGES.txt Sat Sep 17 16:26:43 2011 @@ -7,6 +7,9 @@ http://s.apache.org/luceneversions Bug fixes +* SOLR-2762: (backport form 4.x line): FSTLookup could return duplicate + results or one results less than requested. (David Smiley, Dawid Weiss) + * LUCENE-3412: SloppyPhraseScorer was returning non-deterministic results - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2215) paging collector
[ https://issues.apache.org/jira/browse/LUCENE-2215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107182#comment-13107182 ] Grant Ingersoll commented on LUCENE-2215: - +1. paging collector Key: LUCENE-2215 URL: https://issues.apache.org/jira/browse/LUCENE-2215 Project: Lucene - Java Issue Type: New Feature Components: core/search Affects Versions: 2.4, 3.0 Reporter: Adam Heinz Assignee: Grant Ingersoll Priority: Minor Attachments: IterablePaging.java, LUCENE-2215.patch, LUCENE-2215.patch, LUCENE-2215.patch, PagingCollector.java, TestingPagingCollector.java http://issues.apache.org/jira/browse/LUCENE-2127?focusedCommentId=12796898page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12796898 Somebody assign this to Aaron McCurry and we'll see if we can get enough votes on this issue to convince him to upload his patch. :) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2776) Support group.truncate for distributed grouping
[ https://issues.apache.org/jira/browse/SOLR-2776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn van Groningen updated SOLR-2776: Attachment: SOLR-2776.patch Added patch that makes support for groups.truncate possible for distributed searches. Support group.truncate for distributed grouping --- Key: SOLR-2776 URL: https://issues.apache.org/jira/browse/SOLR-2776 Project: Solr Issue Type: Improvement Reporter: Martijn van Groningen Assignee: Martijn van Groningen Fix For: 3.5, 4.0 Attachments: SOLR-2776.patch Currently group.truncate isn't supported when executing a distributed grouped search. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3215) SloppyPhraseScorer sometimes computes Infinite freq
[ https://issues.apache.org/jira/browse/LUCENE-3215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107209#comment-13107209 ] Doron Cohen commented on LUCENE-3215: - OK I think I have a fix for this. While looking at it, I realized that PhraseScorer (the one that used to base both ExactSloppy phrase scorers but now is the base of only sloppy phrase scorer) is way too complicated and inefficient. All those sort calls after each matching doc can be avoided. So I am modifying PhraseScorer to not have a phrase-queue at all - just the sorted linked list, which is always kept sorted by advancing last beyond first. Last is renamed to 'min' and first is renamed to 'max'. Making the list cyclic allows more efficient manipulation of it. With this, SloppyPhraseScorer is modified to maintain its own phrase queue. The queue size is set at the first candidate document. In order to handle repetitions (Same term in different query offsets) it will contain only some of the pps: those that either have no repetitions, or are the first (lower query offset) in a repeating group. A linked list of repeating pps was added: so PhrasePositions has a new member: nextRepeating. Detection of repeating pps and creation of that list is done once per scorer: at the first candidate doc. For solving the bugs reported here, in addition to the initiation of 'end' as explained in previous comment, advanceRepeatingPPs now also update two values: - end, in case one of the repeating pps is far ahead (larger) - position of the first pp in a repeating list (the one that is in the queue - in case the repeating pp is far behind (smaller). This can happen when there are holes in the query, as position = tpPOs - offset. It fixes the problem of false negative distances which caused this bug. It is tricky: relies on that PhrasePositions.nextPosition() ignores pp.position and just call positions.nextPosition(). But it is correct, as the modified position is used to replace pp in the queue. Last, I think that the test added with holes had one wrong assert: It added four docs: - drug drug - drug druggy drug - drug druggy druggy drug - drug druggy drug druggy drug defined this query (number is the offset): - drug(1) drug(3) and expected that with slop=1 the first doc would not be found. I think it should be found, as the slop operates in both directions. So modified the query to: drug(1) drug(3) Patch to follow. SloppyPhraseScorer sometimes computes Infinite freq --- Key: LUCENE-3215 URL: https://issues.apache.org/jira/browse/LUCENE-3215 Project: Lucene - Java Issue Type: Bug Reporter: Robert Muir Assignee: Doron Cohen Attachments: LUCENE-3215.patch, LUCENE-3215_test.patch, LUCENE-3215_test.patch reported on user list: http://www.lucidimagination.com/search/document/400cbc528ed63db9/score_of_infinity_on_dismax_query -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Edited] (LUCENE-3215) SloppyPhraseScorer sometimes computes Infinite freq
[ https://issues.apache.org/jira/browse/LUCENE-3215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107209#comment-13107209 ] Doron Cohen edited comment on LUCENE-3215 at 9/17/11 6:56 PM: -- OK I think I have a fix for this. While looking at it, I realized that PhraseScorer (the one that used to base both ExactSloppy phrase scorers but now is the base of only sloppy phrase scorer) is way too complicated and inefficient. All those sort calls after each matching doc can be avoided. So I am modifying PhraseScorer to not have a phrase-queue at all - just the sorted linked list, which is always kept sorted by advancing last beyond first. Last is renamed to 'min' and first is renamed to 'max'. Making the list cyclic allows more efficient manipulation of it. With this, SloppyPhraseScorer is modified to maintain its own phrase queue. The queue size is set at the first candidate document. In order to handle repetitions (Same term in different query offsets) it will contain only some of the pps: those that either have no repetitions, or are the first (lower query offset) in a repeating group. A linked list of repeating pps was added: so PhrasePositions has a new member: nextRepeating. Detection of repeating pps and creation of that list is done once per scorer: at the first candidate doc. For solving the bugs reported here, in addition to the initiation of 'end' as explained in previous comment, advanceRepeatingPPs now also update two values: - end, in case one of the repeating pps is far ahead (larger) - position of the first pp in a repeating list (the one that is in the queue - in case the repeating pp is far behind (smaller). This can happen when there are holes in the query, as position = tpPOs - offset. It fixes the problem of false negative distances which caused this bug. It is tricky: relies on that PhrasePositions.nextPosition() ignores pp.position and just call positions.nextPosition(). But it is correct, as the modified position is used to replace pp in the queue. Last, I think that the test added with holes had one wrong assert: It added four docs: - drug drug - drug druggy drug - drug druggy druggy drug - drug druggy drug druggy drug defined this query (number is the offset): - drug(1) drug(3) and expected that with slop=1 the first doc would not be found. I think it should be found, as the slop operates in both directions. So modified the query to: drug(1) drug(3) Patch to follow. was (Author: doronc): OK I think I have a fix for this. While looking at it, I realized that PhraseScorer (the one that used to base both ExactSloppy phrase scorers but now is the base of only sloppy phrase scorer) is way too complicated and inefficient. All those sort calls after each matching doc can be avoided. So I am modifying PhraseScorer to not have a phrase-queue at all - just the sorted linked list, which is always kept sorted by advancing last beyond first. Last is renamed to 'min' and first is renamed to 'max'. Making the list cyclic allows more efficient manipulation of it. With this, SloppyPhraseScorer is modified to maintain its own phrase queue. The queue size is set at the first candidate document. In order to handle repetitions (Same term in different query offsets) it will contain only some of the pps: those that either have no repetitions, or are the first (lower query offset) in a repeating group. A linked list of repeating pps was added: so PhrasePositions has a new member: nextRepeating. Detection of repeating pps and creation of that list is done once per scorer: at the first candidate doc. For solving the bugs reported here, in addition to the initiation of 'end' as explained in previous comment, advanceRepeatingPPs now also update two values: - end, in case one of the repeating pps is far ahead (larger) - position of the first pp in a repeating list (the one that is in the queue - in case the repeating pp is far behind (smaller). This can happen when there are holes in the query, as position = tpPOs - offset. It fixes the problem of false negative distances which caused this bug. It is tricky: relies on that PhrasePositions.nextPosition() ignores pp.position and just call positions.nextPosition(). But it is correct, as the modified position is used to replace pp in the queue. Last, I think that the test added with holes had one wrong assert: It added four docs: - drug drug - drug druggy drug - drug druggy druggy drug - drug druggy drug druggy drug defined this query (number is the offset): - drug(1) drug(3) and expected that with slop=1 the first doc would not be found. I think it should be found, as the slop operates in both directions. So modified the query to: drug(1) drug(3) Patch to follow. SloppyPhraseScorer sometimes computes Infinite freq ---
[jira] [Updated] (LUCENE-3215) SloppyPhraseScorer sometimes computes Infinite freq
[ https://issues.apache.org/jira/browse/LUCENE-3215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Doron Cohen updated LUCENE-3215: Attachment: LUCENE-3215.patch Attached patch is based on r1166541 - before recent changes to scorers. Will merge with recent changes tomorrow or so. All tests pass. I believe that sloppy scoring performance should improve with this change but did not check this. SloppyPhraseScorer sometimes computes Infinite freq --- Key: LUCENE-3215 URL: https://issues.apache.org/jira/browse/LUCENE-3215 Project: Lucene - Java Issue Type: Bug Reporter: Robert Muir Assignee: Doron Cohen Attachments: LUCENE-3215.patch, LUCENE-3215.patch, LUCENE-3215_test.patch, LUCENE-3215_test.patch reported on user list: http://www.lucidimagination.com/search/document/400cbc528ed63db9/score_of_infinity_on_dismax_query -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
trunk test failure (1316284082)
A test failure occurred running the tests. revert! revert! revert! You can see the entire build log at http://sierranevada.servebeer.com/1316284082.log Thanks, Charlie Cron - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3215) SloppyPhraseScorer sometimes computes Infinite freq
[ https://issues.apache.org/jira/browse/LUCENE-3215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Doron Cohen updated LUCENE-3215: Attachment: LUCENE-3215.patch Updated patch for current trunk r1172055. SloppyPhraseScorer sometimes computes Infinite freq --- Key: LUCENE-3215 URL: https://issues.apache.org/jira/browse/LUCENE-3215 Project: Lucene - Java Issue Type: Bug Reporter: Robert Muir Assignee: Doron Cohen Attachments: LUCENE-3215.patch, LUCENE-3215.patch, LUCENE-3215.patch, LUCENE-3215_test.patch, LUCENE-3215_test.patch reported on user list: http://www.lucidimagination.com/search/document/400cbc528ed63db9/score_of_infinity_on_dismax_query -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2757) Switch min(a,b) function to min(a,b,...)
[ https://issues.apache.org/jira/browse/SOLR-2757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107239#comment-13107239 ] Bill Bell commented on SOLR-2757: - Can we get his committed. I have tested it extensively. Patch for 3x is needed. Switch min(a,b) function to min(a,b,...) Key: SOLR-2757 URL: https://issues.apache.org/jira/browse/SOLR-2757 Project: Solr Issue Type: Improvement Affects Versions: 3.4 Reporter: Bill Bell Priority: Minor Attachments: SOLR-2757.patch Original Estimate: 1h Remaining Estimate: 1h Would like the ability to use min(1,5,10,11) to return 1. To do that today it is parenthesis nightmare: min(min(min(1,5),10),11) Should extend max() as well. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
trunk test failure (1316292302)
A test failure occurred running the tests. revert! revert! revert! You can see the entire build log at http://sierranevada.servebeer.com/1316292302.log Thanks, Charlie Cron - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
trunk test failure (1316295181)
A test failure occurred running the tests. revert! revert! revert! You can see the entire build log at http://sierranevada.servebeer.com/1316295181.log Thanks, Charlie Cron - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-2779) org.apache.solr.common should be in apache-solr-common-3.4.0.jar
org.apache.solr.common should be in apache-solr-common-3.4.0.jar Key: SOLR-2779 URL: https://issues.apache.org/jira/browse/SOLR-2779 Project: Solr Issue Type: New Feature Components: clients - java Affects Versions: 3.4 Reporter: Gang Luo Priority: Trivial org.apache.solr.common.ResourceLoader in apache-solr-solrj-3.4.0.jar now. apache-solr-solrj-3.4.0.jar for solr client ? org.apache.solr.common.ResourceLoader should be in apache-solr-common-3.4.0.jar ? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2779) org.apache.solr.common should be in apache-solr-common-3.4.0.jar
[ https://issues.apache.org/jira/browse/SOLR-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107309#comment-13107309 ] Steven Rowe commented on SOLR-2779: --- Hi Gang Luo, Please ask about this kind of thing on the solr-user mailing list before making a JIRA issue. Why do you think ResourceLoader should be a jar that currently does not exist? org.apache.solr.common should be in apache-solr-common-3.4.0.jar Key: SOLR-2779 URL: https://issues.apache.org/jira/browse/SOLR-2779 Project: Solr Issue Type: New Feature Components: clients - java Affects Versions: 3.4 Reporter: Gang Luo Priority: Trivial Labels: common, jar Original Estimate: 1h Remaining Estimate: 1h org.apache.solr.common.ResourceLoader in apache-solr-solrj-3.4.0.jar now. apache-solr-solrj-3.4.0.jar for solr client ? org.apache.solr.common.ResourceLoader should be in apache-solr-common-3.4.0.jar ? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2779) org.apache.solr.common should be in apache-solr-common-3.4.0.jar
[ https://issues.apache.org/jira/browse/SOLR-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107311#comment-13107311 ] Robert Muir commented on SOLR-2779: --- I do think its strange you need to depend upon solrj just to e.g. load up a text file in an analysis plugin or something (as you need to link ResourceLoaderAware/ResourceLoader) org.apache.solr.common should be in apache-solr-common-3.4.0.jar Key: SOLR-2779 URL: https://issues.apache.org/jira/browse/SOLR-2779 Project: Solr Issue Type: New Feature Components: clients - java Affects Versions: 3.4 Reporter: Gang Luo Priority: Trivial Labels: common, jar Original Estimate: 1h Remaining Estimate: 1h org.apache.solr.common.ResourceLoader in apache-solr-solrj-3.4.0.jar now. apache-solr-solrj-3.4.0.jar for solr client ? org.apache.solr.common.ResourceLoader should be in apache-solr-common-3.4.0.jar ? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-1895) ManifoldCF SearchComponent plugin for enforcing ManifoldCF security at search time
[ https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koji Sekiguchi updated SOLR-1895: - Attachment: SOLR-1895.patch Added more tests. Still testUserTokens() doesn't pass (tests are commented out) ManifoldCF SearchComponent plugin for enforcing ManifoldCF security at search time -- Key: SOLR-1895 URL: https://issues.apache.org/jira/browse/SOLR-1895 Project: Solr Issue Type: New Feature Components: SearchComponents - other Reporter: Karl Wright Labels: document, security, solr Fix For: 3.5, 4.0 Attachments: LCFSecurityFilter.java, LCFSecurityFilter.java, LCFSecurityFilter.java, LCFSecurityFilter.java, SOLR-1895.patch, SOLR-1895.patch, SOLR-1895.patch I've written an LCF SearchComponent which filters returned results based on access tokens provided by LCF's authority service. The component requires you to configure the appropriate authority service URL base, e.g.: !-- LCF document security enforcement component -- searchComponent name=lcfSecurity class=LCFSecurityFilter str name=AuthorityServiceBaseURLhttp://localhost:8080/lcf-authority-service/str /searchComponent Also required are the following schema.xml additions: !-- Security fields -- field name=allow_token_document type=string indexed=true stored=false multiValued=true/ field name=deny_token_document type=string indexed=true stored=false multiValued=true/ field name=allow_token_share type=string indexed=true stored=false multiValued=true/ field name=deny_token_share type=string indexed=true stored=false multiValued=true/ Finally, to tie it into the standard request handler, it seems to need to run last: requestHandler name=standard class=solr.SearchHandler default=true arr name=last-components strlcfSecurity/str /arr ... I have not set a package for this code. Nor have I been able to get it reviewed by someone as conversant with Solr as I would prefer. It is my hope, however, that this module will become part of the standard Solr 1.5 suite of search components, since that would tie it in with LCF nicely. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1895) ManifoldCF SearchComponent plugin for enforcing ManifoldCF security at search time
[
https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107329#comment-13107329
]
Koji Sekiguchi commented on SOLR-1895:
--
I figured out why the test doesn't pass. In this test, I provided the following
documents:
{code}
// | share| document
// |--|--
// | allow | deny | allow | deny
// -+---+--+---+--
// d-a12| | | 1, 2 |
// -+---+--+---+--
// d-a1-d3 | | | 1 | 3
// -+---+--+---+--
// s-d13| | 1, 3 | |
// -+---+--+---+--
// ds-a23-d1| 3 | 1| 2 |
// -+---+--+---+--
// notoken | | | |
// -+---+--+---+--
{code}
and when querying *:* with UserTokens=token2, I expected that I got d-a12,
s-d13, ds-a23-d1 and notoken. But in reality, Solr returns d-a12 and notoken.
This can be explained as follows:
# ManifoldCFSecurityFilter constructs a filter (FS) that finds docs for *share
part* using the following logic in calculateCompleteSubfilter():
{code}
/** Calculate a complete subclause, representing something like:
* ((fieldAllowShare is empty AND fieldDenyShare is empty) OR fieldAllowShare
HAS token1 OR fieldAllowShare HAS token2 ...)
* AND fieldDenyShare DOESN'T_HAVE token1 AND fieldDenyShare DOESN'T_HAVE
token2 ...
*/
{code}
# As the result of the filter, we got d-a12, d-a1-d3 and notoken (Hmm, I would
like to get s-d13 here)
# Then ManifoldCFSecurityFilter constructs a filter (FD) that finds docs for
*document part* using the same logic in calculateCompleteSubfilter()
# As the result of the filter, we got d-a12, s-d13, ds-a23-d1 and notoken
# Finally, ManifoldCFSecurityFilter constructs the final filter using above two
filters:
{code}
BooleanFilter bf = new BooleanFilter();
bf.add(FS,Occur.MUST);
bf.add(FD,Occur.MUST);
{code}
ManifoldCF SearchComponent plugin for enforcing ManifoldCF security at search
time
--
Key: SOLR-1895
URL: https://issues.apache.org/jira/browse/SOLR-1895
Project: Solr
Issue Type: New Feature
Components: SearchComponents - other
Reporter: Karl Wright
Labels: document, security, solr
Fix For: 3.5, 4.0
Attachments: LCFSecurityFilter.java, LCFSecurityFilter.java,
LCFSecurityFilter.java, LCFSecurityFilter.java, SOLR-1895.patch,
SOLR-1895.patch, SOLR-1895.patch
I've written an LCF SearchComponent which filters returned results based on
access tokens provided by LCF's authority service. The component requires
you to configure the appropriate authority service URL base, e.g.:
!-- LCF document security enforcement component --
searchComponent name=lcfSecurity class=LCFSecurityFilter
str
name=AuthorityServiceBaseURLhttp://localhost:8080/lcf-authority-service/str
/searchComponent
Also required are the following schema.xml additions:
!-- Security fields --
field name=allow_token_document type=string indexed=true
stored=false multiValued=true/
field name=deny_token_document type=string indexed=true
stored=false multiValued=true/
field name=allow_token_share type=string indexed=true
stored=false multiValued=true/
field name=deny_token_share type=string indexed=true stored=false
multiValued=true/
Finally, to tie it into the standard request handler, it seems to need to run
last:
requestHandler name=standard class=solr.SearchHandler default=true
arr name=last-components
strlcfSecurity/str
/arr
...
I have not set a package for this code. Nor have I been able to get it
reviewed by someone as conversant with Solr as I would prefer. It is my
hope, however, that this module will become part of the standard Solr 1.5
suite of search components, since that would tie it in with LCF nicely.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Edited] (SOLR-1895) ManifoldCF SearchComponent plugin for enforcing ManifoldCF security at search time
[
https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107329#comment-13107329
]
Koji Sekiguchi edited comment on SOLR-1895 at 9/18/11 3:46 AM:
---
I figured out why the test doesn't pass. In this test, I provided the following
documents:
{code}
// | share| document
// |--|--
// | allow | deny | allow | deny
// -+---+--+---+--
// d-a12| | | 1, 2 |
// -+---+--+---+--
// d-a1-d3 | | | 1 | 3
// -+---+--+---+--
// s-d13| | 1, 3 | |
// -+---+--+---+--
// ds-a23-d1| 3 | 1| 2 |
// -+---+--+---+--
// notoken | | | |
// -+---+--+---+--
{code}
and when querying *:* with UserTokens=token2, I expected that I got d-a12,
s-d13, ds-a23-d1 and notoken. But in reality, Solr returns d-a12 and notoken.
This can be explained as follows:
# ManifoldCFSecurityFilter constructs a filter (FS) that finds docs for *share
part* using the following logic in calculateCompleteSubfilter():
{code}
/** Calculate a complete subclause, representing something like:
* ((fieldAllowShare is empty AND fieldDenyShare is empty) OR fieldAllowShare
HAS token1 OR fieldAllowShare HAS token2 ...)
* AND fieldDenyShare DOESN'T_HAVE token1 AND fieldDenyShare DOESN'T_HAVE
token2 ...
*/
{code}
# As the result of the filter, we got d-a12, d-a1-d3 and notoken (Hmm, I would
like to get s-d13 here)
# Then ManifoldCFSecurityFilter constructs a filter (FD) that finds docs for
*document part* using the same logic in calculateCompleteSubfilter()
# As the result of the filter, we got d-a12, s-d13, ds-a23-d1 and notoken
# Finally, ManifoldCFSecurityFilter constructs the final filter using above two
filters:
{code}
BooleanFilter bf = new BooleanFilter();
bf.add(FS,Occur.MUST);
bf.add(FD,Occur.MUST);
{code}
was (Author: koji):
I figured out why the test doesn't pass. In this test, I provided the
following documents:
{code}
// | share| document
// |--|--
// | allow | deny | allow | deny
// -+---+--+---+--
// d-a12| | | 1, 2 |
// -+---+--+---+--
// d-a1-d3 | | | 1 | 3
// -+---+--+---+--
// s-d13| | 1, 3 | |
// -+---+--+---+--
// ds-a23-d1| 3 | 1| 2 |
// -+---+--+---+--
// notoken | | | |
// -+---+--+---+--
{code}
and when querying *:* with UserTokens=token2, I expected that I got d-a12,
s-d13, ds-a23-d1 and notoken. But in reality, Solr returns d-a12 and notoken.
This can be explained as follows:
# ManifoldCFSecurityFilter constructs a filter (FS) that finds docs for *share
part* using the following logic in calculateCompleteSubfilter():
{code}
/** Calculate a complete subclause, representing something like:
* ((fieldAllowShare is empty AND fieldDenyShare is empty) OR fieldAllowShare
HAS token1 OR fieldAllowShare HAS token2 ...)
* AND fieldDenyShare DOESN'T_HAVE token1 AND fieldDenyShare DOESN'T_HAVE
token2 ...
*/
{code}
# As the result of the filter, we got d-a12, d-a1-d3 and notoken (Hmm, I would
like to get s-d13 here)
# Then ManifoldCFSecurityFilter constructs a filter (FD) that finds docs for
*document part* using the same logic in calculateCompleteSubfilter()
# As the result of the filter, we got d-a12, s-d13, ds-a23-d1 and notoken
# Finally, ManifoldCFSecurityFilter constructs the final filter using above two
filters:
{code}
BooleanFilter bf = new BooleanFilter();
bf.add(FS,Occur.MUST);
bf.add(FD,Occur.MUST);
{code}
ManifoldCF SearchComponent plugin for enforcing ManifoldCF security at search
time
--
Key: SOLR-1895
URL: https://issues.apache.org/jira/browse/SOLR-1895
Project: Solr
Issue Type: New Feature
Components: SearchComponents - other
Reporter: Karl Wright
Labels: document, security, solr
Fix For: 3.5, 4.0
Attachments: LCFSecurityFilter.java, LCFSecurityFilter.java,
LCFSecurityFilter.java, LCFSecurityFilter.java, SOLR-1895.patch,
SOLR-1895.patch, SOLR-1895.patch
I've written an LCF SearchComponent which filters returned results based on
access tokens provided by LCF's authority service. The component requires
you to configure the appropriate authority service URL base, e.g.:
!-- LCF document security enforcement component --
searchComponent name=lcfSecurity class=LCFSecurityFilter
str
[jira] [Issue Comment Edited] (SOLR-1895) ManifoldCF SearchComponent plugin for enforcing ManifoldCF security at search time
[
https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107329#comment-13107329
]
Koji Sekiguchi edited comment on SOLR-1895 at 9/18/11 3:47 AM:
---
I figured out why the test doesn't pass. In this test, I provided the following
documents:
{code}
// | share| document
// |--|--
// | allow | deny | allow | deny
// -+---+--+---+--
// d-a12| | | 1, 2 |
// -+---+--+---+--
// d-a1-d3 | | | 1 | 3
// -+---+--+---+--
// s-d13| | 1, 3 | |
// -+---+--+---+--
// ds-a23-d1| 3 | 1| 2 |
// -+---+--+---+--
// notoken | | | |
// -+---+--+---+--
{code}
and when querying **:** with UserTokens=token2, I expected that I got d-a12,
s-d13, ds-a23-d1 and notoken. But in reality, Solr returns d-a12 and notoken.
This can be explained as follows:
# ManifoldCFSecurityFilter constructs a filter (FS) that finds docs for *share
part* using the following logic in calculateCompleteSubfilter():
{code}
/** Calculate a complete subclause, representing something like:
* ((fieldAllowShare is empty AND fieldDenyShare is empty) OR fieldAllowShare
HAS token1 OR fieldAllowShare HAS token2 ...)
* AND fieldDenyShare DOESN'T_HAVE token1 AND fieldDenyShare DOESN'T_HAVE
token2 ...
*/
{code}
# As the result of the filter, we got d-a12, d-a1-d3 and notoken (Hmm, I would
like to get s-d13 here)
# Then ManifoldCFSecurityFilter constructs a filter (FD) that finds docs for
*document part* using the same logic in calculateCompleteSubfilter()
# As the result of the filter, we got d-a12, s-d13, ds-a23-d1 and notoken
# Finally, ManifoldCFSecurityFilter constructs the final filter using above two
filters:
{code}
BooleanFilter bf = new BooleanFilter();
bf.add(FS,Occur.MUST);
bf.add(FD,Occur.MUST);
{code}
was (Author: koji):
I figured out why the test doesn't pass. In this test, I provided the
following documents:
{code}
// | share| document
// |--|--
// | allow | deny | allow | deny
// -+---+--+---+--
// d-a12| | | 1, 2 |
// -+---+--+---+--
// d-a1-d3 | | | 1 | 3
// -+---+--+---+--
// s-d13| | 1, 3 | |
// -+---+--+---+--
// ds-a23-d1| 3 | 1| 2 |
// -+---+--+---+--
// notoken | | | |
// -+---+--+---+--
{code}
and when querying *:* with UserTokens=token2, I expected that I got d-a12,
s-d13, ds-a23-d1 and notoken. But in reality, Solr returns d-a12 and notoken.
This can be explained as follows:
# ManifoldCFSecurityFilter constructs a filter (FS) that finds docs for *share
part* using the following logic in calculateCompleteSubfilter():
{code}
/** Calculate a complete subclause, representing something like:
* ((fieldAllowShare is empty AND fieldDenyShare is empty) OR fieldAllowShare
HAS token1 OR fieldAllowShare HAS token2 ...)
* AND fieldDenyShare DOESN'T_HAVE token1 AND fieldDenyShare DOESN'T_HAVE
token2 ...
*/
{code}
# As the result of the filter, we got d-a12, d-a1-d3 and notoken (Hmm, I would
like to get s-d13 here)
# Then ManifoldCFSecurityFilter constructs a filter (FD) that finds docs for
*document part* using the same logic in calculateCompleteSubfilter()
# As the result of the filter, we got d-a12, s-d13, ds-a23-d1 and notoken
# Finally, ManifoldCFSecurityFilter constructs the final filter using above two
filters:
{code}
BooleanFilter bf = new BooleanFilter();
bf.add(FS,Occur.MUST);
bf.add(FD,Occur.MUST);
{code}
ManifoldCF SearchComponent plugin for enforcing ManifoldCF security at search
time
--
Key: SOLR-1895
URL: https://issues.apache.org/jira/browse/SOLR-1895
Project: Solr
Issue Type: New Feature
Components: SearchComponents - other
Reporter: Karl Wright
Labels: document, security, solr
Fix For: 3.5, 4.0
Attachments: LCFSecurityFilter.java, LCFSecurityFilter.java,
LCFSecurityFilter.java, LCFSecurityFilter.java, SOLR-1895.patch,
SOLR-1895.patch, SOLR-1895.patch
I've written an LCF SearchComponent which filters returned results based on
access tokens provided by LCF's authority service. The component requires
you to configure the appropriate authority service URL base, e.g.:
!-- LCF document security enforcement component --
searchComponent name=lcfSecurity class=LCFSecurityFilter
[jira] [Resolved] (SOLR-2594) Make Replication Handler cloud aware
[ https://issues.apache.org/jira/browse/SOLR-2594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otis Gospodnetic resolved SOLR-2594. Resolution: Won't Fix Resolving as Won't Fix as suggested. Make Replication Handler cloud aware Key: SOLR-2594 URL: https://issues.apache.org/jira/browse/SOLR-2594 Project: Solr Issue Type: Improvement Components: replication (java), SolrCloud Reporter: Shalin Shekhar Mangar Fix For: 4.0 Replication handler should be cloud aware. It should be possible to switch roles from slave to master as well as switch masterUrls based on the cluster topology and state. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
