[jira] Created: (SOLR-788) MoreLikeThis should support distributed search
MoreLikeThis should support distributed search -- Key: SOLR-788 URL: https://issues.apache.org/jira/browse/SOLR-788 Project: Solr Issue Type: Improvement Reporter: Grant Ingersoll Priority: Minor The MoreLikeThis component should support distributed processing. See SOLR-303. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (SOLR-560) Convert JDK logging to SLF4J
[ https://issues.apache.org/jira/browse/SOLR-560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll reopened SOLR-560: -- You need to add in the license information to the license file. http://www.slf4j.org/license.html See solr/lib/README.committers.txt Convert JDK logging to SLF4J Key: SOLR-560 URL: https://issues.apache.org/jira/browse/SOLR-560 Project: Solr Issue Type: Wish Reporter: Ryan McKinley Assignee: Ryan McKinley Fix For: 1.4 Attachments: slf4j-api-1.5.0.jar, slf4j-jdk14-1.5.0.jar, SOLR-560-slf4j.patch, SOLR-560-slf4j.patch, SOLR-560-slf4j.patch, SOLR-560-slf4j.patch After lots of discussion, we should consider using SLF4j to enable more flexibility in logging configuration. See: http://www.nabble.com/Solr-Logging-td16836646.html http://www.nabble.com/logging-through-log4j-td13747253.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-787) SolrJ POM refers to stax parser
[ https://issues.apache.org/jira/browse/SOLR-787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-787: --- Attachment: SOLR-787.patch Patch with necessary changes to solrj pom. I'll commit shortly. SolrJ POM refers to stax parser --- Key: SOLR-787 URL: https://issues.apache.org/jira/browse/SOLR-787 Project: Solr Issue Type: Bug Affects Versions: 1.3 Reporter: Shalin Shekhar Mangar Priority: Minor Fix For: 1.3.1 Attachments: SOLR-787.patch Solr core moved to using woodstox instead of stax but SolrJ POM still has a dependency to stax. We should replace the dependency to stax with woodstox jar in SolrJ's POM. This is not a huge problem as we are not distributing stax anymore but is needed for consistency. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-787) SolrJ POM refers to stax parser
[ https://issues.apache.org/jira/browse/SOLR-787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar resolved SOLR-787. Resolution: Fixed Assignee: Shalin Shekhar Mangar Committed revision 699333. SolrJ POM refers to stax parser --- Key: SOLR-787 URL: https://issues.apache.org/jira/browse/SOLR-787 Project: Solr Issue Type: Bug Affects Versions: 1.3 Reporter: Shalin Shekhar Mangar Assignee: Shalin Shekhar Mangar Priority: Minor Fix For: 1.3.1 Attachments: SOLR-787.patch Solr core moved to using woodstox instead of stax but SolrJ POM still has a dependency to stax. We should replace the dependency to stax with woodstox jar in SolrJ's POM. This is not a huge problem as we are not distributing stax anymore but is needed for consistency. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-560) Convert JDK logging to SLF4J
[ https://issues.apache.org/jira/browse/SOLR-560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley resolved SOLR-560. Resolution: Fixed added license to LICENSE.txt so we should have duplicate info in NOTICE.txt and LICENSE.txt? or should the license in NOTICE.txt be removed? http://svn.apache.org/viewvc/lucene/solr/trunk/NOTICE.txt?r1=696539r2=696538pathrev=696539 Convert JDK logging to SLF4J Key: SOLR-560 URL: https://issues.apache.org/jira/browse/SOLR-560 Project: Solr Issue Type: Wish Reporter: Ryan McKinley Assignee: Ryan McKinley Fix For: 1.4 Attachments: slf4j-api-1.5.0.jar, slf4j-jdk14-1.5.0.jar, SOLR-560-slf4j.patch, SOLR-560-slf4j.patch, SOLR-560-slf4j.patch, SOLR-560-slf4j.patch After lots of discussion, we should consider using SLF4j to enable more flexibility in logging configuration. See: http://www.nabble.com/Solr-Logging-td16836646.html http://www.nabble.com/logging-through-log4j-td13747253.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-651) A SearchComponent for fetching TF-IDF values
[ https://issues.apache.org/jira/browse/SOLR-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12634877#action_12634877 ] Shalin Shekhar Mangar commented on SOLR-651: Grant, would it be better to handle the distributed case through another issue and commit the fully baked patch for a single server? A lot of people can start using it immediately. Distributed Search is still relatively rare though it is certainly picking up the pace. A SearchComponent for fetching TF-IDF values Key: SOLR-651 URL: https://issues.apache.org/jira/browse/SOLR-651 Project: Solr Issue Type: New Feature Affects Versions: 1.3 Reporter: Noble Paul Assignee: Grant Ingersoll Priority: Minor Fix For: 1.4 Attachments: SOLR-651.patch, SOLR-651.patch, SOLR-651.patch A SearchComponent that can return TF-IDF vector for any given document in the SOLR index Query : A Document Number / a query identifying a Document Response : A Map of term vs.TF-IDF value of every term in the Selected Document Why ? Most of the Machine Learning Algorithms work on TFIDF representation of documents, hence adding a Request Handler proving the TFIDF representation will pave the way for incorporating Learning Paradigms to SOLR framework. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-560) Convert JDK logging to SLF4J
[ https://issues.apache.org/jira/browse/SOLR-560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12634885#action_12634885 ] Grant Ingersoll commented on SOLR-560: -- AIUI, the LICENSE file needs to contain all licenses. NOTICES needs to contain notices, and not licenses. I don't think it needs to be duplicated. Convert JDK logging to SLF4J Key: SOLR-560 URL: https://issues.apache.org/jira/browse/SOLR-560 Project: Solr Issue Type: Wish Reporter: Ryan McKinley Assignee: Ryan McKinley Fix For: 1.4 Attachments: slf4j-api-1.5.0.jar, slf4j-jdk14-1.5.0.jar, SOLR-560-slf4j.patch, SOLR-560-slf4j.patch, SOLR-560-slf4j.patch, SOLR-560-slf4j.patch After lots of discussion, we should consider using SLF4j to enable more flexibility in logging configuration. See: http://www.nabble.com/Solr-Logging-td16836646.html http://www.nabble.com/logging-through-log4j-td13747253.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-789) The javadoc of RandomSortField is not readable
The javadoc of RandomSortField is not readable -- Key: SOLR-789 URL: https://issues.apache.org/jira/browse/SOLR-789 Project: Solr Issue Type: Bug Components: documentation Affects Versions: 1.3 Reporter: Nicolas Lalevée Priority: Minor see http://lucene.apache.org/solr/api/org/apache/solr/schema/RandomSortField.html The javadoc is formatted textually in the source, but not for the HTML presentation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-789) The javadoc of RandomSortField is not readable
[ https://issues.apache.org/jira/browse/SOLR-789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Lalevée updated SOLR-789: - Attachment: SOLR-789-r699359.patch Here is a patch against the trunk The javadoc of RandomSortField is not readable -- Key: SOLR-789 URL: https://issues.apache.org/jira/browse/SOLR-789 Project: Solr Issue Type: Bug Components: documentation Affects Versions: 1.3 Reporter: Nicolas Lalevée Priority: Minor Attachments: SOLR-789-r699359.patch see http://lucene.apache.org/solr/api/org/apache/solr/schema/RandomSortField.html The javadoc is formatted textually in the source, but not for the HTML presentation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-790) Make solr/build.xml. importable into a parent project
Make solr/build.xml. importable into a parent project - Key: SOLR-790 URL: https://issues.apache.org/jira/browse/SOLR-790 Project: Solr Issue Type: Improvement Reporter: Dan Rosher Priority: Minor Make solr/build.xml importable into a parent project, and work standalone as it does now. Assumptions in common-build.xml about dest output locations updated subant tasks for contrib (DIH) updated to accept all inherited properties DIH build.xml works standalone as it does now, and as part the build if a parent to solr imports the solr project -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-790) Make solr/build.xml. importable into a parent project
[ https://issues.apache.org/jira/browse/SOLR-790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Rosher updated SOLR-790: Attachment: SOLR-790.patch Make solr/build.xml. importable into a parent project - Key: SOLR-790 URL: https://issues.apache.org/jira/browse/SOLR-790 Project: Solr Issue Type: Improvement Reporter: Dan Rosher Priority: Minor Attachments: SOLR-790.patch Make solr/build.xml importable into a parent project, and work standalone as it does now. Assumptions in common-build.xml about dest output locations updated subant tasks for contrib (DIH) updated to accept all inherited properties DIH build.xml works standalone as it does now, and as part the build if a parent to solr imports the solr project -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-791) Allow to submit config and schema when creating a new core
Allow to submit config and schema when creating a new core
--
Key: SOLR-791
URL: https://issues.apache.org/jira/browse/SOLR-791
Project: Solr
Issue Type: New Feature
Components: clients - java
Affects Versions: 1.3
Reporter: Gunnar Wagenknecht
Currently it's possible to create cores remotely via SolrJ.
{code}
CoreAdminRequest.createCore(acore, acoreinstancedir, adminServer);
{code}
However, this process is incomplete because I need to manually log onto the
remote server and place a configuration file as well as a schema file into the
{{conf/}} folder in the {{acoreinstancedir/}}. It would be great it I can
simply submit those files together with the create core request.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-617) Allow configurable deletion policy
[
https://issues.apache.org/jira/browse/SOLR-617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Akshay K. Ukey updated SOLR-617:
Attachment: solr-617.patch
Patch with changes suggested by Shalin and logging using slf4j.
Allow configurable deletion policy
--
Key: SOLR-617
URL: https://issues.apache.org/jira/browse/SOLR-617
Project: Solr
Issue Type: New Feature
Components: search, update
Affects Versions: 1.4
Reporter: Noble Paul
Assignee: Shalin Shekhar Mangar
Priority: Minor
Fix For: 1.4
Attachments: 617.patch, solr-617.patch, solr-617.patch,
solr-617.patch, solr-617.patch
Lucene API provides means to configure deletion policy. Solr should be able
to expose it through configuration in solrconfig.xml. Moreover the new
replication (SOLR-561) strategy is going to rely on this .
I propose the configuration go into the mainIndex section
sample configuration
{code:xml|title=solrconfig.xml}
mainIndex
!-- configure deletion policy here--
deletionPolicy
!-- Store only the commits with optimize.Non optimized commits will
get deleted by lucene when
the last IndexWriter/IndexReader using this commit point is
closed --
keepOptimizedOnlytrue/keepOptimizedOnly
!--Maximum no: of commit points stored . Older ones will be cleaned
when they go out of scope--
maxCommitsToKeep/maxCommitsToKeep
!-- max age of a stored commit--
maxCommitAge/maxCommitAge
/deletionPolicy
/mainIndex
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: bug or clarifiation?
On Wed, Sep 24, 2008 at 2:38 PM, Erik Hatcher [EMAIL PROTECTED] wrote: except that ipod doesn't become a *boosting* query, it becomes a narrowing clause: str name=parsedquery +cat:electronics +DisjunctionMaxQuery((name:ipod)) () /str Why is it that SHOULD is not used when a boosting query is already an unboosted boolean query? But, I think the original purpose of bq was to add clauses to the main query... so in that sense it's working as designed. If bq contains mandatory or prohibited clauses, then they become mandatory or prohibited clauses of the main query. -Yonik
[jira] Created: (SOLR-792) Tree Faceting Component
Tree Faceting Component --- Key: SOLR-792 URL: https://issues.apache.org/jira/browse/SOLR-792 Project: Solr Issue Type: New Feature Reporter: Erik Hatcher Assignee: Erik Hatcher Priority: Minor A component to do multi-level faceting. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-792) Tree Faceting Component
[
https://issues.apache.org/jira/browse/SOLR-792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik Hatcher updated SOLR-792:
--
Attachment: SOLR-792.patch
This patch is a simple implementation to do a fixed two-level faceting, using
the SimpleFacets functions. This is just the start. The idea is to make the
actual faceting implementation pluggable, support arbitrary levels, perhaps
also support nested facet queries, not just facet fields.
With this patch, this query, on Solr's example data set, returns the data below:
http://localhost:8983/solr/select?q=*:*rows=0facet=onfacet.field=catfacet.tree=cat,inStockwt=jsonindent=on
facet_counts:{
facet_queries:{},
facet_fields:{
cat:[
electronics,14,
memory,3,
card,2,
connector,2,
drive,2,
graphics,2,
hard,2,
monitor,2,
search,2,
software,2,
camera,1,
copier,1,
multifunction,1,
music,1,
printer,1,
scanner,1]},
facet_dates:{},
trees:[
cat,inStock,[
electronics,[
true,10,
false,4],
memory,[
true,3,
false,0],
card,[
false,2,
true,0],
connector,[
false,2,
true,0],
drive,[
true,2,
false,0],
graphics,[
false,2,
true,0],
hard,[
true,2,
false,0],
monitor,[
true,2,
false,0],
search,[
true,2,
false,0],
software,[
true,2,
false,0],
camera,[
true,1,
false,0],
copier,[
true,1,
false,0],
multifunction,[
true,1,
false,0],
music,[
true,1,
false,0],
printer,[
true,1,
false,0],
scanner,[
true,1,
false,0]]]}}
Tree Faceting Component
---
Key: SOLR-792
URL: https://issues.apache.org/jira/browse/SOLR-792
Project: Solr
Issue Type: New Feature
Reporter: Erik Hatcher
Assignee: Erik Hatcher
Priority: Minor
Attachments: SOLR-792.patch
A component to do multi-level faceting.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-792) Tree Faceting Component
[ https://issues.apache.org/jira/browse/SOLR-792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12635010#action_12635010 ] Shalin Shekhar Mangar commented on SOLR-792: Is it this related to (or same as) SOLR-64 ? Tree Faceting Component --- Key: SOLR-792 URL: https://issues.apache.org/jira/browse/SOLR-792 Project: Solr Issue Type: New Feature Reporter: Erik Hatcher Assignee: Erik Hatcher Priority: Minor Attachments: SOLR-792.patch A component to do multi-level faceting. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-617) Allow configurable deletion policy
[
https://issues.apache.org/jira/browse/SOLR-617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar updated SOLR-617:
---
Attachment: solr-617.patch
Updated with more javadocs and comments in solrconfig.xml
I think this is ready to go in. I'll commit this in a day or two if there are
no objection.
Allow configurable deletion policy
--
Key: SOLR-617
URL: https://issues.apache.org/jira/browse/SOLR-617
Project: Solr
Issue Type: New Feature
Components: search, update
Affects Versions: 1.4
Reporter: Noble Paul
Assignee: Shalin Shekhar Mangar
Priority: Minor
Fix For: 1.4
Attachments: 617.patch, solr-617.patch, solr-617.patch,
solr-617.patch, solr-617.patch, solr-617.patch
Lucene API provides means to configure deletion policy. Solr should be able
to expose it through configuration in solrconfig.xml. Moreover the new
replication (SOLR-561) strategy is going to rely on this .
I propose the configuration go into the mainIndex section
sample configuration
{code:xml|title=solrconfig.xml}
mainIndex
!-- configure deletion policy here--
deletionPolicy
!-- Store only the commits with optimize.Non optimized commits will
get deleted by lucene when
the last IndexWriter/IndexReader using this commit point is
closed --
keepOptimizedOnlytrue/keepOptimizedOnly
!--Maximum no: of commit points stored . Older ones will be cleaned
when they go out of scope--
maxCommitsToKeep/maxCommitsToKeep
!-- max age of a stored commit--
maxCommitAge/maxCommitAge
/deletionPolicy
/mainIndex
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-667) Alternate LRUCache implementation
[
https://issues.apache.org/jira/browse/SOLR-667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley updated SOLR-667:
--
Attachment: ConcurrentLRUCache.java
Here is a prototype of an idea I've had for a while for an efficient concurrent
LRU cache.
It is completely untested... consider it more code as design. It *should*
feature faster cleaning - O( n ) when it works well.
In addition to low and high water marks, it adds the concept of an acceptable
water mark. A cleaning phase will try to go to the low water mark, but will be
considered successful if it hits the acceptable water mark.
This is coupled with a multi-pass cleaning phase. From the comments:
{code}
// if we want to keep at least 1000 entries, then timestamps of
// current through current-1000 are guaranteed not to be the oldest!
// Also, if we want to remove 500 entries, then
// oldestEntry through oldestEntry+500 are guaranteed to be
// removed.
{code}
The oldestEntry and newestEntry in the set of entries currently being
considered is recorded for each phase. Entries that are new enough such that
they are guaranteed to be kept are immediately removed from consideration, and
entries that are old enough such that they are guaranteed to be removed are
immediately removed (no sorting necessary). After 2 phases of this
(configurable) and we still haven't removed enough entries, a priority queue is
used to find the oldest entries out of those remaining.
There are undoubtedly some other tricks we can use, but this was the best I
could come up with for now.
Alternate LRUCache implementation
-
Key: SOLR-667
URL: https://issues.apache.org/jira/browse/SOLR-667
Project: Solr
Issue Type: New Feature
Components: search
Affects Versions: 1.3
Reporter: Noble Paul
Fix For: 1.4
Attachments: ConcurrentLRUCache.java, ConcurrentLRUCache.java,
ConcurrentLRUCache.java, SOLR-667.patch, SOLR-667.patch, SOLR-667.patch,
SOLR-667.patch
The only available SolrCache i.e LRUCache is based on _LinkedHashMap_ which
has _get()_ also synchronized. This can cause severe bottlenecks for faceted
search. Any alternate implementation which can be faster/better must be
considered.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-792) Tree Faceting Component
[ https://issues.apache.org/jira/browse/SOLR-792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12635078#action_12635078 ] Hoss Man commented on SOLR-792: --- SOLR-64 is (in theory) about better faceting support for fields that represent a hierarchy. What Erik is addressing seems to me more like generating an N- dimensional matrix of facet counts Tree Faceting Component --- Key: SOLR-792 URL: https://issues.apache.org/jira/browse/SOLR-792 Project: Solr Issue Type: New Feature Reporter: Erik Hatcher Assignee: Erik Hatcher Priority: Minor Attachments: SOLR-792.patch A component to do multi-level faceting. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-789) The javadoc of RandomSortField is not readable
[ https://issues.apache.org/jira/browse/SOLR-789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koji Sekiguchi resolved SOLR-789. - Resolution: Fixed Fix Version/s: 1.3.1 Assignee: Koji Sekiguchi Committed revision 699549. Thanks Nicolas! The javadoc of RandomSortField is not readable -- Key: SOLR-789 URL: https://issues.apache.org/jira/browse/SOLR-789 Project: Solr Issue Type: Bug Components: documentation Affects Versions: 1.3 Reporter: Nicolas Lalevée Assignee: Koji Sekiguchi Priority: Minor Fix For: 1.3.1 Attachments: SOLR-789-r699359.patch see http://lucene.apache.org/solr/api/org/apache/solr/schema/RandomSortField.html The javadoc is formatted textually in the source, but not for the HTML presentation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
