[jira] Updated: (SOLR-1776) dismax and edismax should treate schema's default field as a default qf
[ https://issues.apache.org/jira/browse/SOLR-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-1776: --- Description: the DismaxQParser (and ExtendedDismaxQParser) is completely useless w/o specifying the "qf" param, but for the life of me i can't think of any good reason why it shouldn't use IndexSchema.getDefaultSearchFieldName() as teh default value for hte qf param. (was: the DismaxQParser is completely useless w/o specifying the "qf" param, but for the life of me i can't think of any good reason why it shouldn't use IndexSchema.getDefaultSearchFieldName() as teh default value for hte qf param.) Summary: dismax and edismax should treate schema's default field as a default qf (was: dismax should treate schema's default field as a default qf) > dismax and edismax should treate schema's default field as a default qf > --- > > Key: SOLR-1776 > URL: https://issues.apache.org/jira/browse/SOLR-1776 > Project: Solr > Issue Type: Improvement >Reporter: Hoss Man >Assignee: Hoss Man > Fix For: 1.5 > > > the DismaxQParser (and ExtendedDismaxQParser) is completely useless w/o > specifying the "qf" param, but for the life of me i can't think of any good > reason why it shouldn't use IndexSchema.getDefaultSearchFieldName() as teh > default value for hte qf param. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1776) dismax should treate schema's default field as a default qf
[ https://issues.apache.org/jira/browse/SOLR-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man resolved SOLR-1776. Resolution: Fixed Fix Version/s: 1.5 Assignee: Hoss Man Committed revision 915646. > dismax should treate schema's default field as a default qf > --- > > Key: SOLR-1776 > URL: https://issues.apache.org/jira/browse/SOLR-1776 > Project: Solr > Issue Type: Improvement >Reporter: Hoss Man >Assignee: Hoss Man > Fix For: 1.5 > > > the DismaxQParser is completely useless w/o specifying the "qf" param, but > for the life of me i can't think of any good reason why it shouldn't use > IndexSchema.getDefaultSearchFieldName() as teh default value for hte qf param. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1792) Document peculiar behavior of TestHarness.LocalRequestFactory
[ https://issues.apache.org/jira/browse/SOLR-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man resolved SOLR-1792. Resolution: Fixed Committed revision 915637. > Document peculiar behavior of TestHarness.LocalRequestFactory > - > > Key: SOLR-1792 > URL: https://issues.apache.org/jira/browse/SOLR-1792 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.1.0, 1.2, 1.3, 1.4 >Reporter: Hoss Man >Assignee: Hoss Man > Fix For: 1.5 > > Attachments: SOLR-1792.patch > > > While working on a test case, i realized that due to method evolution, > TestHarness.LocalRequestFactory.makeRequest has some really odd behavior that > results in the "defaults" the factory was configured with being ignored when > the method is called with multiple varargs. > I spent some time attempting to "fix" this by adding the defaults to the end > of the params, but then discovered that this breaks existing tests because > the LRF defaults take precedence over defaults that may be hardcoded into the > solrconfig.xml. The internal test might be changed to work arround this, but > i didn't want to risk breaking tests for users who might be using TestHarness > directly. > So this bug is just to track improving the documentation of what exactly > LRF.makeRequest does with it's input -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1792) Document peculiar behavior of TestHarness.LocalRequestFactory
[ https://issues.apache.org/jira/browse/SOLR-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-1792: --- Attachment: SOLR-1792.patch patch ... i would have already committed this but SVN seems to be down. > Document peculiar behavior of TestHarness.LocalRequestFactory > - > > Key: SOLR-1792 > URL: https://issues.apache.org/jira/browse/SOLR-1792 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.1.0, 1.2, 1.3, 1.4 >Reporter: Hoss Man >Assignee: Hoss Man > Fix For: 1.5 > > Attachments: SOLR-1792.patch > > > While working on a test case, i realized that due to method evolution, > TestHarness.LocalRequestFactory.makeRequest has some really odd behavior that > results in the "defaults" the factory was configured with being ignored when > the method is called with multiple varargs. > I spent some time attempting to "fix" this by adding the defaults to the end > of the params, but then discovered that this breaks existing tests because > the LRF defaults take precedence over defaults that may be hardcoded into the > solrconfig.xml. The internal test might be changed to work arround this, but > i didn't want to risk breaking tests for users who might be using TestHarness > directly. > So this bug is just to track improving the documentation of what exactly > LRF.makeRequest does with it's input -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1792) Document peculiar behavior of TestHarness.LocalRequestFactory
Document peculiar behavior of TestHarness.LocalRequestFactory - Key: SOLR-1792 URL: https://issues.apache.org/jira/browse/SOLR-1792 Project: Solr Issue Type: Improvement Affects Versions: 1.4, 1.3, 1.2, 1.1.0 Reporter: Hoss Man Assignee: Hoss Man Fix For: 1.5 While working on a test case, i realized that due to method evolution, TestHarness.LocalRequestFactory.makeRequest has some really odd behavior that results in the "defaults" the factory was configured with being ignored when the method is called with multiple varargs. I spent some time attempting to "fix" this by adding the defaults to the end of the params, but then discovered that this breaks existing tests because the LRF defaults take precedence over defaults that may be hardcoded into the solrconfig.xml. The internal test might be changed to work arround this, but i didn't want to risk breaking tests for users who might be using TestHarness directly. So this bug is just to track improving the documentation of what exactly LRF.makeRequest does with it's input -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1724) Real Basic Core Management with Zookeeper
[ https://issues.apache.org/jira/browse/SOLR-1724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Rutherglen updated SOLR-1724: --- Attachment: SOLR-1724.patch I added a test case that simulates attempting to install a bad core. Still need to get the backup a Solr core to HDFS working. > Real Basic Core Management with Zookeeper > - > > Key: SOLR-1724 > URL: https://issues.apache.org/jira/browse/SOLR-1724 > Project: Solr > Issue Type: New Feature > Components: multicore >Affects Versions: 1.4 >Reporter: Jason Rutherglen > Fix For: 1.5 > > Attachments: commons-lang-2.4.jar, gson-1.4.jar, > hadoop-0.20.2-dev-core.jar, hadoop-0.20.2-dev-test.jar, SOLR-1724.patch, > SOLR-1724.patch, SOLR-1724.patch, SOLR-1724.patch, SOLR-1724.patch, > SOLR-1724.patch, SOLR-1724.patch, SOLR-1724.patch > > > Though we're implementing cloud, I need something real soon I can > play with and deploy. So this'll be a patch that only deploys > new cores, and that's about it. The arch is real simple: > On Zookeeper there'll be a directory that contains files that > represent the state of the cores of a given set of servers which > will look like the following: > /production/cores-1.txt > /production/cores-2.txt > /production/core-host-1-actual.txt (ephemeral node per host) > Where each core-N.txt file contains: > hostname,corename,instanceDir,coredownloadpath > coredownloadpath is a URL such as file://, http://, hftp://, hdfs://, ftp://, > etc > and > core-host-actual.txt contains: > hostname,corename,instanceDir,size > Everytime a new core-N.txt file is added, the listening host > finds it's entry in the list and begins the process of trying to > match the entries. Upon completion, it updates it's > /core-host-1-actual.txt file to it's completed state or logs an error. > When all host actual files are written (without errors), then a > new core-1-actual.txt file is written which can be picked up by > another process that can create a new core proxy. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1622) Add aggregate Math capabilities to Solr above and beyond the StatsComponent
[
https://issues.apache.org/jira/browse/SOLR-1622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12837488#action_12837488
]
Randy Prager commented on SOLR-1622:
any thought on having this as part of 1.5?
> Add aggregate Math capabilities to Solr above and beyond the StatsComponent
> ---
>
> Key: SOLR-1622
> URL: https://issues.apache.org/jira/browse/SOLR-1622
> Project: Solr
> Issue Type: New Feature
> Components: search
>Reporter: Grant Ingersoll
>Priority: Minor
>
> It would be really cool if we could have a QueryComponent that enabled doing
> aggregating calculations on search results similar to what the StatsComponent
> does, but in a more generic way.
> I also think it makes sense to reuse some of the function query capabilities
> (like the parser, etc.).
> I imagine the interface might look like:
> {code}
> math=true&func=recip(sum(A))
> {code}
> This would calculate the reciprocal of the sum of the values in the field A.
> Then, you could do go across fields, too
> {code}
> math=true&func=recip(sum(A, B, C))
> {code}
> Which would sum the values across fields A, B and C.
> It is important to make the functions pluggable and reusable. Might be also
> nice to see if we can share the core calculations between function queries
> and this capability such that if someone adds a new aggregating function, it
> can also be used as a new Function query.
> Of course, we'd want plugin functions, too, so that people can plugin their
> own functions. After this is implemented, I think StatsComponent becomes a
> derivative of the new MathComponent.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1791) core names messed up in multicore
[ https://issues.apache.org/jira/browse/SOLR-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12837480#action_12837480 ] Yonik Seeley commented on SOLR-1791: I've fixed this in the cloud branch since it needed some CoreAdmin changes that mark already made there. > core names messed up in multicore > - > > Key: SOLR-1791 > URL: https://issues.apache.org/jira/browse/SOLR-1791 > Project: Solr > Issue Type: Bug >Reporter: Yonik Seeley >Priority: Minor > Fix For: 1.5 > > > If you start the multicore example and go to the admin page, the core names > will be messed up (objects instead of names). > This worked in 1.4 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1791) core names messed up in multicore
core names messed up in multicore - Key: SOLR-1791 URL: https://issues.apache.org/jira/browse/SOLR-1791 Project: Solr Issue Type: Bug Reporter: Yonik Seeley Priority: Minor Fix For: 1.5 If you start the multicore example and go to the admin page, the core names will be messed up (objects instead of names). This worked in 1.4 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1787) CachedSqlEntityProcessor pre-warmed cache use case
[ https://issues.apache.org/jira/browse/SOLR-1787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12837424#action_12837424 ] Michael Henson commented on SOLR-1787: -- There isn't any new code to make a pre-warming call. The design relies on filling the cache on the first call to getAllNonCachedRows(). I'm also relying on the synchronize block of ThreadedEntityProcessorWrapper.nextRow() to block other threads while the cache filling query runs. It looks like I'm missing some aspect of multi-threading because I get SQLException's with "could not execute query" when I have threads="3" on the root entity. > CachedSqlEntityProcessor pre-warmed cache use case > -- > > Key: SOLR-1787 > URL: https://issues.apache.org/jira/browse/SOLR-1787 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Affects Versions: 1.5 > Environment: jdk 1.6.x, windows xp, tomcat 6.x >Reporter: Michael Henson >Assignee: Noble Paul >Priority: Minor > Fix For: 1.5 > > Attachments: solr-1787.patch > > > The CachedSqlEntityProcessor currently builds a cache of rows it sees as it > goes, so later requests for that same key can be served from data that has > already been fetched. The primary query could be written to fetch all > possible rows, which would then be set into the cache on the first request > for a row. In that case the database would only receive another query when > there is a cache miss. However, the query it would execute is the one that > pulls all rows, negating any performance gain. > This patch adds the ability to configure behavior on cache miss with the > "onCacheMiss" attribute on an "entity" tag in the data-config.xml file. The > current behavior is the default, corresponding to the setting > onCacheMiss="fill". Any other value explicitly given for onCacheMiss will > cause cache misses to be ignored - no query will be made to the db to fulfill > them. > I've encountered two cases where this capability is useful: > 1. Relatively small datasets, such as category id -> category name mappings, > which will not change during the course of indexing. > 2. Queries which are heavy on db resources per-query, particularly if the > query for an individual record is slow, and can't be fixed easily on the db > side for whatever reason. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1724) Real Basic Core Management with Zookeeper
[ https://issues.apache.org/jira/browse/SOLR-1724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12837418#action_12837418 ] Jason Rutherglen commented on SOLR-1724: We need a test case with a partial install, and cleaning up any extraneous files afterwards > Real Basic Core Management with Zookeeper > - > > Key: SOLR-1724 > URL: https://issues.apache.org/jira/browse/SOLR-1724 > Project: Solr > Issue Type: New Feature > Components: multicore >Affects Versions: 1.4 >Reporter: Jason Rutherglen > Fix For: 1.5 > > Attachments: commons-lang-2.4.jar, gson-1.4.jar, > hadoop-0.20.2-dev-core.jar, hadoop-0.20.2-dev-test.jar, SOLR-1724.patch, > SOLR-1724.patch, SOLR-1724.patch, SOLR-1724.patch, SOLR-1724.patch, > SOLR-1724.patch, SOLR-1724.patch > > > Though we're implementing cloud, I need something real soon I can > play with and deploy. So this'll be a patch that only deploys > new cores, and that's about it. The arch is real simple: > On Zookeeper there'll be a directory that contains files that > represent the state of the cores of a given set of servers which > will look like the following: > /production/cores-1.txt > /production/cores-2.txt > /production/core-host-1-actual.txt (ephemeral node per host) > Where each core-N.txt file contains: > hostname,corename,instanceDir,coredownloadpath > coredownloadpath is a URL such as file://, http://, hftp://, hdfs://, ftp://, > etc > and > core-host-actual.txt contains: > hostname,corename,instanceDir,size > Everytime a new core-N.txt file is added, the listening host > finds it's entry in the list and begins the process of trying to > match the entries. Upon completion, it updates it's > /core-host-1-actual.txt file to it's completed state or logs an error. > When all host actual files are written (without errors), then a > new core-1-actual.txt file is written which can be picked up by > another process that can create a new core proxy. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Lucene Flex
Is SOLR compatible with Lucene 3* or Flex branch?
[jira] Updated: (SOLR-1790) XPath entity processor problem with empty fields processing.
[ https://issues.apache.org/jira/browse/SOLR-1790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Laxman updated SOLR-1790: - Description: Xpath entity processor has following problem with processing the empty fields. While processing XML containing a field with empty value, its fetching the next fields value. When I import the follow record into SOLR by DIH ... http://apache.org ... When I query the record, the return result is not the same as expect: There is no "ContentURL" field, instead there is a field "keywords" has content "http://apache.org";. was: Xpath entity processor has following problem with processing the empty fields. While processing XML containing a field with empty value, its fetching the next fields value. When I import the follow record into SOLR by DIH http://www.sina.com When I query the record, the return result is not the same as expect: There is no "ContentURL" field, instead there is a field "keywords" has content "http://www.sina.com";. > XPath entity processor problem with empty fields processing. > > > Key: SOLR-1790 > URL: https://issues.apache.org/jira/browse/SOLR-1790 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler >Affects Versions: 1.4, 1.5 >Reporter: Laxman > Fix For: 1.5 > > Original Estimate: 72h > Remaining Estimate: 72h > > Xpath entity processor has following problem with processing the empty fields. > While processing XML containing a field with empty value, its fetching the > next fields value. > When I import the follow record into SOLR by DIH > > ... > > > http://apache.org > > ... > > When I query the record, the return result is not the same as expect: > There is no "ContentURL" field, instead there is a field "keywords" has > content "http://apache.org";. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1790) XPath entity processor problem with empty fields processing.
XPath entity processor problem with empty fields processing. Key: SOLR-1790 URL: https://issues.apache.org/jira/browse/SOLR-1790 Project: Solr Issue Type: Bug Components: contrib - DataImportHandler Affects Versions: 1.4, 1.5 Reporter: Laxman Fix For: 1.5 Xpath entity processor has following problem with processing the empty fields. While processing XML containing a field with empty value, its fetching the next fields value. When I import the follow record into SOLR by DIH http://www.sina.com When I query the record, the return result is not the same as expect: There is no "ContentURL" field, instead there is a field "keywords" has content "http://www.sina.com";. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1789) maven solr-core pom should depend on servlet api
maven solr-core pom should depend on servlet api Key: SOLR-1789 URL: https://issues.apache.org/jira/browse/SOLR-1789 Project: Solr Issue Type: Bug Components: Build Affects Versions: 1.4 Reporter: David Smiley Priority: Trivial Fix For: 1.5 EmbeddedSolrServer, in Solr core, uses org.apache.solr.servlet.SolrRequestParsers which (as its package reflects) depends on the servlet API. Fix: Add the following to solr-core-pom.xml.template: javax.servlet servlet-api 2.4 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1787) CachedSqlEntityProcessor pre-warmed cache use case
[ https://issues.apache.org/jira/browse/SOLR-1787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12837251#action_12837251 ] Noble Paul commented on SOLR-1787: -- is pre-warming done in this patch? > CachedSqlEntityProcessor pre-warmed cache use case > -- > > Key: SOLR-1787 > URL: https://issues.apache.org/jira/browse/SOLR-1787 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Affects Versions: 1.5 > Environment: jdk 1.6.x, windows xp, tomcat 6.x >Reporter: Michael Henson >Priority: Minor > Fix For: 1.5 > > Attachments: solr-1787.patch > > > The CachedSqlEntityProcessor currently builds a cache of rows it sees as it > goes, so later requests for that same key can be served from data that has > already been fetched. The primary query could be written to fetch all > possible rows, which would then be set into the cache on the first request > for a row. In that case the database would only receive another query when > there is a cache miss. However, the query it would execute is the one that > pulls all rows, negating any performance gain. > This patch adds the ability to configure behavior on cache miss with the > "onCacheMiss" attribute on an "entity" tag in the data-config.xml file. The > current behavior is the default, corresponding to the setting > onCacheMiss="fill". Any other value explicitly given for onCacheMiss will > cause cache misses to be ignored - no query will be made to the db to fulfill > them. > I've encountered two cases where this capability is useful: > 1. Relatively small datasets, such as category id -> category name mappings, > which will not change during the course of indexing. > 2. Queries which are heavy on db resources per-query, particularly if the > query for an individual record is slow, and can't be fixed easily on the db > side for whatever reason. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-1787) CachedSqlEntityProcessor pre-warmed cache use case
[ https://issues.apache.org/jira/browse/SOLR-1787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul reassigned SOLR-1787: Assignee: Noble Paul > CachedSqlEntityProcessor pre-warmed cache use case > -- > > Key: SOLR-1787 > URL: https://issues.apache.org/jira/browse/SOLR-1787 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Affects Versions: 1.5 > Environment: jdk 1.6.x, windows xp, tomcat 6.x >Reporter: Michael Henson >Assignee: Noble Paul >Priority: Minor > Fix For: 1.5 > > Attachments: solr-1787.patch > > > The CachedSqlEntityProcessor currently builds a cache of rows it sees as it > goes, so later requests for that same key can be served from data that has > already been fetched. The primary query could be written to fetch all > possible rows, which would then be set into the cache on the first request > for a row. In that case the database would only receive another query when > there is a cache miss. However, the query it would execute is the one that > pulls all rows, negating any performance gain. > This patch adds the ability to configure behavior on cache miss with the > "onCacheMiss" attribute on an "entity" tag in the data-config.xml file. The > current behavior is the default, corresponding to the setting > onCacheMiss="fill". Any other value explicitly given for onCacheMiss will > cause cache misses to be ignored - no query will be made to the db to fulfill > them. > I've encountered two cases where this capability is useful: > 1. Relatively small datasets, such as category id -> category name mappings, > which will not change during the course of indexing. > 2. Queries which are heavy on db resources per-query, particularly if the > query for an individual record is slow, and can't be fixed easily on the db > side for whatever reason. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
error in sum function
-- View this message in context: http://old.nabble.com/error-in-sum-function-tp27701692p27701692.html Sent from the Solr - Dev mailing list archive at Nabble.com.
Re: Solrj @Field getter annotation
On Mon, Feb 22, 2010 at 11:50 PM, Norman Wiechmann wrote: > Noble Paul നോബിള് नोब्ळ् wrote: >> >> if it is not provided with setters , what do you suggest? provide it >> with getters? > > yes, i would like to have the @Field annotation at getters. and if there is > no reason against this i can provide a patch for DocumentObjectBinder that > adds getter annotation and keeps the setter annotation for backward > compatibility. I personally don't think it makes a lot of difference just because other JPA tools don't follow that pattern. So removing the annotation from the setter is not required > > best, Norman > -- - Noble Paul | Systems Architect| AOL | http://aol.com
