date:20090818



On Aug 17, 2009, at 10:15 PM, Yonik Seeley wrote:



Too high level for Lucene I think, and nothing is currently needed for
Lucene - a user calls doc() to get the document and then they can
modify or add fields however they want.

An interface could be useful for Solr... but getting 1.4 out the door
is top priority.


Agreed, I think I may make a simple mod to the SolrPluginUtils for now  
to allow callback there.  That would at least save one extra loop and  
it wouldn't require any lower-level changes.

Re: good performance news



On Aug 18, 2009, at 1:58 AM, Noble Paul നോബിള്‍  
नोब्ळ् wrote:



I our internal testing , the binary request writer gave very good perf
for large no:of docs.


Yeah, that only makes sense.  I was just curious on the overhead of  
XML in typical cases.  I think all the native clients should use  
binary format.




Though we did not benchmark it

On Tue, Aug 18, 2009 at 2:57 AM, Grant  
Ingersollgsing...@apache.org wrote:


On Aug 16, 2009, at 3:46 PM, Yonik Seeley wrote:


I just profiled a CSV upload, and aside from the CSV parsing, Solr
adds pretty much no overhead!
I was expecting some non-trivial overhead due to Solr's
SolrInputDocument, update processing pipeline, and update handler...
but profiling showed that it amounted to less than 1%.

85% of the time was spent in Lucene's IndexWriter
12% of the time was spent in the CSV parser2


I'm curious how much overhead there is in parsing Solr XML.  I will  
try some
tests on that later if I get a chance.  We really should push  
clients to use

the Binary request/response formats in most cases.





--
-
Noble Paul | Principal Engineer| AOL | http://aol.com

[jira] Created: (SOLR-1367) Provide Callback mechanism for SolrPluginUtils.docListToSolrDocumentList

Provide Callback mechanism for SolrPluginUtils.docListToSolrDocumentList


 Key: SOLR-1367
 URL: https://issues.apache.org/jira/browse/SOLR-1367
 Project: Solr
  Issue Type: Improvement
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
 Fix For: 1.4


Sometimes SearchComponents need to modify the DocList.  Often times this 
requires two loops over the (Solr)DocList: once to convert the DocList to 
SolrDocList and then once to iterate the SolrDocList for the Search Component.  
This can be seen in SOLR-773, for example.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-1367) Provide Callback mechanism for SolrPluginUtils.docListToSolrDocumentList


 [ 
https://issues.apache.org/jira/browse/SOLR-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Grant Ingersoll updated SOLR-1367:
--

Attachment: SOLR-1367.patch

Simple fix for this.  Marked the interface as changeable pending some other 
fixes later.

 Provide Callback mechanism for SolrPluginUtils.docListToSolrDocumentList
 

 Key: SOLR-1367
 URL: https://issues.apache.org/jira/browse/SOLR-1367
 Project: Solr
  Issue Type: Improvement
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
 Fix For: 1.4

 Attachments: SOLR-1367.patch


 Sometimes SearchComponents need to modify the DocList.  Often times this 
 requires two loops over the (Solr)DocList: once to convert the DocList to 
 SolrDocList and then once to iterate the SolrDocList for the Search 
 Component.  This can be seen in SOLR-773, for example.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Response Writers and DocLists



On Aug 18, 2009, at 8:25 AM, Grant Ingersoll wrote:



On Aug 17, 2009, at 10:15 PM, Yonik Seeley wrote:



Too high level for Lucene I think, and nothing is currently needed  
for

Lucene - a user calls doc() to get the document and then they can
modify or add fields however they want.

An interface could be useful for Solr... but getting 1.4 out the door
is top priority.


Agreed, I think I may make a simple mod to the SolrPluginUtils for  
now to allow callback there.  That would at least save one extra  
loop and it wouldn't require any lower-level changes.


See SOLR-1367 for the SolrPluginUtils change.

Re: Response Writers and DocLists



On Aug 18, 2009, at 9:49 AM, Ryan McKinley wrote:




Also, I'm thinking about having a real simple interface that would  
allow

for, when materializing the Fields, to pass in something like a
DocumentModifier, which would basically get the document right  
before it is
to be returned (possibly inside the SolrIndexReader, but maybe  
this even
belongs at the Lucene level similar to the FieldSelector, although  
it is
likely too late for 2.9.)  Through this DocModifier, one could  
easily add

fields, etc.


Too high level for Lucene I think, and nothing is currently needed  
for

Lucene - a user calls doc() to get the document and then they can
modify or add fields however they want.

An interface could be useful for Solr... but getting 1.4 out the door
is top priority.



Agreed... i am wondering if pushing:
https://issues.apache.org/jira/browse/SOLR-705
to 1.4 makes sense...


It already is marked for 1.4 and has been for a while.

[jira] Commented: (SOLR-1143) Return partial results when a connection to a shard is refused


[ 
https://issues.apache.org/jira/browse/SOLR-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744518#action_12744518
 ] 

Grant Ingersoll commented on SOLR-1143:
---

I'm not sure about the need for the return-partial-results static boolean.  
This could just be handled through the RequestHandler defaults, right?

 Return partial results when a connection to a shard is refused
 --

 Key: SOLR-1143
 URL: https://issues.apache.org/jira/browse/SOLR-1143
 Project: Solr
  Issue Type: Improvement
  Components: search
Reporter: Nicolas Dessaigne
 Fix For: 1.4

 Attachments: SOLR-1143-2.patch, SOLR-1143.patch


 If any shard is down in a distributed search, a ConnectException it thrown.
 Here's a little patch that change this behaviour: if we can't connect to a 
 shard (ConnectException), we get partial results from the active shards. As 
 for TimeOut parameter (https://issues.apache.org/jira/browse/SOLR-502), we 
 set the parameter partialResults at true.
 This patch also adresses a problem expressed in the mailing list about a year 
 ago 
 (http://www.nabble.com/partialResults,-distributed-search---SOLR-502-td19002610.html)
 We have a use case that needs this behaviour and we would like to know your 
 thougths about such a behaviour? Should it be the default behaviour for 
 distributed search?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Issue Comment Edited: (SOLR-1143) Return partial results when a connection to a shard is refused


[ 
https://issues.apache.org/jira/browse/SOLR-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744518#action_12744518
 ] 

Grant Ingersoll edited comment on SOLR-1143 at 8/18/09 7:19 AM:


{quote}
In this patch you return a partial result when a shard has failed by setting 
partialResults to true in the request or if you want it to for all requests 
your can add bool name=return-partial-resultstrue/bool to your search 
handler in your solrconfig.xml. If both are not specified, partial results are 
disabled. Currently the partialResults parameter overrides the 
return-partial-results property in the search handler.
{quote}

I'm not sure about the need for the return-partial-results static boolean.  
This could just be handled through the RequestHandler defaults, right?

  was (Author: gsingers):
I'm not sure about the need for the return-partial-results static boolean.  
This could just be handled through the RequestHandler defaults, right?
  
 Return partial results when a connection to a shard is refused
 --

 Key: SOLR-1143
 URL: https://issues.apache.org/jira/browse/SOLR-1143
 Project: Solr
  Issue Type: Improvement
  Components: search
Reporter: Nicolas Dessaigne
 Fix For: 1.4

 Attachments: SOLR-1143-2.patch, SOLR-1143.patch


 If any shard is down in a distributed search, a ConnectException it thrown.
 Here's a little patch that change this behaviour: if we can't connect to a 
 shard (ConnectException), we get partial results from the active shards. As 
 for TimeOut parameter (https://issues.apache.org/jira/browse/SOLR-502), we 
 set the parameter partialResults at true.
 This patch also adresses a problem expressed in the mailing list about a year 
 ago 
 (http://www.nabble.com/partialResults,-distributed-search---SOLR-502-td19002610.html)
 We have a use case that needs this behaviour and we would like to know your 
 thougths about such a behaviour? Should it be the default behaviour for 
 distributed search?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (SOLR-1366) UnsupportedOperationException may be thrown when using custom IndexReader

2009-08-18 Thread Mark Miller (JIRA)


 [ 
https://issues.apache.org/jira/browse/SOLR-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Miller reassigned SOLR-1366:
-

Assignee: Mark Miller

 UnsupportedOperationException may be thrown when using custom IndexReader
 -

 Key: SOLR-1366
 URL: https://issues.apache.org/jira/browse/SOLR-1366
 Project: Solr
  Issue Type: Bug
  Components: search
Affects Versions: 1.4
Reporter: Andrzej Bialecki 
Assignee: Mark Miller
 Fix For: 1.4

 Attachments: searcher.patch


 If a custom IndexReaderFactory is specifiedd in solrconfig.xml, and 
 IndexReader-s that it produces don't support IndexReader.directory() (such as 
 is the case with ParallelReader or MultiReader) then an uncaught 
 UnsupportedOperationException is thrown.
 This call is used only to retrieve the full path of the directory for 
 informational purpose, so it shouldn't lead to a crash. Instead we could 
 supply other available information about the reader (e.g. from its toString() 
 method).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1366) UnsupportedOperationException may be thrown when using custom IndexReader

2009-08-18 Thread Mark Miller (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744542#action_12744542
 ] 

Mark Miller commented on SOLR-1366:
---



bq. This call is used only to retrieve the full path of the directory for 
informational purpose, so it shouldn't lead to a crash. 

The replication handler uses it a lot (assuming its a file) - I almost feel we 
should add some javadoc about how using non FSDirectory based IndexReaders is 
supported. I'm not even fully sure myself.

Also, are we positive it behaves here correctly in SolrCore ?
{code}
  File indexDirFile = new File(getIndexDir()).getCanonicalFile();
  File newIndexDirFile = new File(newIndexDir).getCanonicalFile();
  
  if (newestSearcher != null  solrConfig.reopenReaders
   indexDirFile.equals(newIndexDirFile)) {
{code}

 UnsupportedOperationException may be thrown when using custom IndexReader
 -

 Key: SOLR-1366
 URL: https://issues.apache.org/jira/browse/SOLR-1366
 Project: Solr
  Issue Type: Bug
  Components: search
Affects Versions: 1.4
Reporter: Andrzej Bialecki 
Assignee: Mark Miller
 Fix For: 1.4

 Attachments: searcher.patch


 If a custom IndexReaderFactory is specifiedd in solrconfig.xml, and 
 IndexReader-s that it produces don't support IndexReader.directory() (such as 
 is the case with ParallelReader or MultiReader) then an uncaught 
 UnsupportedOperationException is thrown.
 This call is used only to retrieve the full path of the directory for 
 informational purpose, so it shouldn't lead to a crash. Instead we could 
 supply other available information about the reader (e.g. from its toString() 
 method).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Response Writers and DocLists

2009-08-18 Thread Ryan McKinley



On Aug 18, 2009, at 10:01 AM, Grant Ingersoll wrote:



On Aug 18, 2009, at 9:49 AM, Ryan McKinley wrote:




Also, I'm thinking about having a real simple interface that  
would allow

for, when materializing the Fields, to pass in something like a
DocumentModifier, which would basically get the document right  
before it is
to be returned (possibly inside the SolrIndexReader, but maybe  
this even
belongs at the Lucene level similar to the FieldSelector,  
although it is
likely too late for 2.9.)  Through this DocModifier, one could  
easily add

fields, etc.


Too high level for Lucene I think, and nothing is currently needed  
for

Lucene - a user calls doc() to get the document and then they can
modify or add fields however they want.

An interface could be useful for Solr... but getting 1.4 out the  
door

is top priority.



Agreed... i am wondering if pushing:
https://issues.apache.org/jira/browse/SOLR-705
to 1.4 makes sense...


It already is marked for 1.4 and has been for a while.


dooh, i mean pushing it out of 1.4 (or into 1.5)

ryan

Re: Response Writers and DocLists

2009-08-18 Thread Yonik Seeley

On Tue, Aug 18, 2009 at 11:20 AM, Ryan McKinleyryan...@gmail.com wrote:
 dooh, i mean pushing it out of 1.4 (or into 1.5)

+1 - the feature will undoubtedly be very important in the future, but
probably shouldn't be a blocker for 1.4

-Yonik

[jira] Created: (SOLR-1368) ms() function for date math

ms() function for date math
---

 Key: SOLR-1368
 URL: https://issues.apache.org/jira/browse/SOLR-1368
 Project: Solr
  Issue Type: New Feature
Reporter: Yonik Seeley
 Fix For: 1.4


ms (milliseconds) function to use dates in function queries

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (SOLR-1368) ms() function for date math


 [ 
https://issues.apache.org/jira/browse/SOLR-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yonik Seeley reassigned SOLR-1368:
--

Assignee: Yonik Seeley

 ms() function for date math
 ---

 Key: SOLR-1368
 URL: https://issues.apache.org/jira/browse/SOLR-1368
 Project: Solr
  Issue Type: New Feature
Reporter: Yonik Seeley
Assignee: Yonik Seeley
 Fix For: 1.4


 ms (milliseconds) function to use dates in function queries

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (SOLR-1369) Add HSQLDB Jar to example-dih

2009-08-18 Thread Eric Pugh (JIRA)

Add HSQLDB Jar to example-dih
-

 Key: SOLR-1369
 URL: https://issues.apache.org/jira/browse/SOLR-1369
 Project: Solr
  Issue Type: Improvement
Reporter: Eric Pugh


I went back to show someone the Example-DIH and followed the wiki page 
directions.  I then ran into an error because the hsqldb uses 1.8, and the 
hsqldb.jar I downloaded from hsqldb.org was 1.9.  The 1.9 rc shows up above the 
1.8 version.

I see two approaches:  1) Be clearer on the docs, maybe embed a direct link to 
http://sourceforge.net/projects/hsqldb/files/hsqldb/hsqldb_1_8_0/hsqldb_1_8_0_10.zip/download.
  

2) include hsqldb.jar in the example.  I am assuming the reason this wasn't 
done was because of licensing issues??   

Also, any real reason to zip the hsqldb database?  It's under 20k expanded and 
adds another step.

Figured I'd get the wisdom of the crowds before changing.

Eric

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1368) ms() function for date math


[ 
https://issues.apache.org/jira/browse/SOLR-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744578#action_12744578
 ] 

Yonik Seeley commented on SOLR-1368:


Floats sometimes don't have sufficient precision for subtracting dates:
http://search.lucidimagination.com/search/document/be9fcf5bbc8fd574/date_functions_and_floats

An ms() function both provides a way to introduce date constants, as well as 
subtract them.

examples:
ms(NOW)  a constant
ms(2009-12-14T01:01:01Z)   a constant
ms(field)  a date field (needs to be a trie-date variant that has milliseconds 
available)
ms(field1,field2)  difference in milliseconds
ms(NOW/SECOND,field1)  difference in milliseconds


 ms() function for date math
 ---

 Key: SOLR-1368
 URL: https://issues.apache.org/jira/browse/SOLR-1368
 Project: Solr
  Issue Type: New Feature
Reporter: Yonik Seeley
Assignee: Yonik Seeley
 Fix For: 1.4


 ms (milliseconds) function to use dates in function queries

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-1368) ms() function for date math


 [ 
https://issues.apache.org/jira/browse/SOLR-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yonik Seeley updated SOLR-1368:
---

Attachment: SOLR-1368.patch

Attaching a draft of a patch that seems to work - still needs tests.

 ms() function for date math
 ---

 Key: SOLR-1368
 URL: https://issues.apache.org/jira/browse/SOLR-1368
 Project: Solr
  Issue Type: New Feature
Reporter: Yonik Seeley
Assignee: Yonik Seeley
 Fix For: 1.4

 Attachments: SOLR-1368.patch


 ms (milliseconds) function to use dates in function queries

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (SOLR-1370) call CharFilters in FieldAnalysisRequestHandler

2009-08-18 Thread Koji Sekiguchi (JIRA)

call CharFilters in FieldAnalysisRequestHandler
---

 Key: SOLR-1370
 URL: https://issues.apache.org/jira/browse/SOLR-1370
 Project: Solr
  Issue Type: Bug
  Components: Analysis
Affects Versions: 1.4
Reporter: Koji Sekiguchi
Priority: Minor


Currently, FieldAnalysisRequestHandler doesn't call CharFilters even if 
CharFilters are defined for the fields.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1296) Enable opening IndexReader with termInfosIndexDivisor and setting IndexWriter's termIndexInterval


[ 
https://issues.apache.org/jira/browse/SOLR-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744622#action_12744622
 ] 

Jason Rutherglen commented on SOLR-1296:


bq. This should do the trick... 

Why would we go through the effort?  IW is a public Lucene class.

bq. do we really need solrconfig-termindex.xml

We probably don't want all the tests to have different behavior.  

 Enable opening IndexReader with termInfosIndexDivisor and setting 
 IndexWriter's termIndexInterval
 -

 Key: SOLR-1296
 URL: https://issues.apache.org/jira/browse/SOLR-1296
 Project: Solr
  Issue Type: Improvement
Affects Versions: 1.3
Reporter: Jason Rutherglen
Assignee: Grant Ingersoll
Priority: Trivial
 Fix For: 1.4

 Attachments: SOLR-1296.patch, SOLR-1296.patch, SOLR-1296.patch, 
 SOLR-1296.patch

   Original Estimate: 48h
  Remaining Estimate: 48h

 We need to enable opening an IndexReader with termInfosIndexDivisor set in 
 solrConfig.  
 We need to enable setting the termIndexInterval in SolrIndexConfig.  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: svn commit: r804477 - in /lucene/solr/trunk/example/exampledocs: hd.xml mem.xml sd500.xml vidcard.xml


: URL: http://svn.apache.org/viewvc?rev=804477view=rev
: Log:
: add back timestamps to more example docs

I'm confused ... why add NOW as a hardcoded value to all of these files? 
... why not put 'default=NOW' back into the schema.xml?  (that was the 
whole point of the timestamp field in the example)


-Hoss

Re: svn commit: r804477 - in /lucene/solr/trunk/example/exampledocs: hd.xml mem.xml sd500.xml vidcard.xml

2009-08-18 Thread Yonik Seeley

On Tue, Aug 18, 2009 at 2:03 PM, Chris
Hostetterhossman_luc...@fucit.org wrote:
 : URL: http://svn.apache.org/viewvc?rev=804477view=rev
 : Log:
 : add back timestamps to more example docs

 I'm confused ... why add NOW as a hardcoded value to all of these files?
 ... why not put 'default=NOW' back into the schema.xml?  (that was the
 whole point of the timestamp field in the example)

It's part of having a fast example schema - it doesn't matter if the
example documents are slow, but it does matter if the example schema
is slow because it's doing stuff that others may not care about.

Someone should be able to use the new example schema as-is, with their
own dynamic fields or whatever, and get near-optimal performance.

If you think NOW is a bad date value for the exampledocs, we could
change them to specific dates, but I'd rather avoid any defaults in
the example schema.

-Yonik
http://www.lucidimagination.com

[jira] Commented: (SOLR-1335) load core properties from a properties file

[
https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744629#action_12744629
]

Hoss Man commented on SOLR-1335:

bq. For a single-core the filenames are always hardcoded like solrconfig.xml
and schema.xml. solrconfig.xml filename can be overridden from web.xml,

...and they can be overridden in solr.xml -- that's my main points: you are
adding a filewhose name is hardcoded and can't be changed under any
circumstances. currently solr.xml is the _only_ field with those kinds of
rules, because the solrconfig.xml and schema.xml filenames can be specified in
solr.xml.

I also contest your claim that they are alwasy hardcoded for single cores ...
we've been making definite progress down a path of encouraging people to use
solr.xml even for single core setups, as you say...

bq. I wish the single core also becomes a multicore with one core and all these
confusions can go away.

...i agree with you completley, but it's not going to happen overnight, and
adding more hardcoded things like this is just a step backwards.

Frankly: i don't even thing there should be a default name for this new
properties file, i think that if you want Solr to load properties from a file
for you, you should be required to use solr.xml, and specify a filename there
-- that would also give us the benefit of letting people specify multiple
filenames (which is my other big concern about a single magic filename: there
can be only one of them. for something like schema.xml or solrconfig.xml
that's not the end of the world because merging multiple files doesn't even
make much sense, but property files are extremly simple, and it should be just
as easy to specify 37 of them as it is to specify 1.

bq. Do we really need to do it now because the properties file itself is
optional and adding that to solr.xml can add to more clutter for a feature that
is not widely used . Even if we add it later it is going to be backward
compatible.

If it's something we know we're going to want to do, and it's going to keep the
code simpler in the long run, we might as well do it right the first time.
there's already too much confusion between the distinction between the solr
home dir, and the solr instance dir when dealing with solr.xml ... having a new
magic filename just convolutes matters (looking at the code: i can't
immediately tell, is the property file expected to be in the instanceDir, or
the solr home? ... what if i have both?

bq. do we really have a choice here? Solr needs solr.solr.home to be set as a
system property and all testcases follow this pattern

There shouldn't be any need for a test to set the solr.solr.home system
property ... the TestHarness already takes care of initializing the core with
the appropriate home dir.

(if for some reason this features tickles a bit of core initialization that
doesn't work properly with the TestHarness then we should fix the TestHarness
... it's probably out of date with some of the EmbeddedSolr best practices
anyway)

load core properties from a properties file
---

Key: SOLR-1335
URL: https://issues.apache.org/jira/browse/SOLR-1335
Project: Solr
Issue Type: New Feature
Reporter: Noble Paul
Assignee: Noble Paul
Fix For: 1.4

Attachments: SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch

There are few ways of loading properties in runtime,
# using env property using in the command line
# if you use a multicore drop it in the solr.xml
if not , the only way is to keep separate solrconfig.xml for each instance.
#1 is error prone if the user fails to start with the correct system
property.
In our case we have four different configurations for the same deployment .
And we have to disable replication of solrconfig.xml.
It would be nice if I can distribute four properties file so that our ops can
drop the right one and start Solr. Or it is possible for the operations to
edit a properties file but it is risky to edit solrconfig.xml if he does not
understand solr
I propose a properties file in the instancedir as solrcore.properties . If
present would be loaded and added as core specific properties.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Can synonyms be defined in a multi-valued field or a database?

2009-08-18 Thread Kelly Taylor


I need the ability to remotely administer synonyms for each of my Solr
standalone instances. It seems that my only option is that of uploading a
file per instance, restarting the respective Solr instance(s), and then
rebuilding my indexes. 

Can synonyms be defined in a multi-valued field or a database in place of a
file? Or can synonyms be administered in any way other than editing a file? 

-Kelly
-- 
View this message in context: 
http://www.nabble.com/Can-synonyms-be-defined-in-a-multi-valued-field-or-a-database--tp25030768p25030768.html
Sent from the Solr - Dev mailing list archive at Nabble.com.

Re: svn commit: r804477 - in /lucene/solr/trunk/example/exampledocs: hd.xml mem.xml sd500.xml vidcard.xml

: If you think NOW is a bad date value for the exampledocs, we could
: change them to specific dates, but I'd rather avoid any defaults in
: the example schema.

but that's the whole point of the field ... that's why it's called 
timestamp ... it provides a timestamp of when a document was indexed.

I'd rather just leave the timestampe field completley commented out with 
the comment about how it can be used if you uncomment. leaving a timestamp 
field in w/o a default value, and putting values into doc files is relaly 
confusing.

We have other date fields we can use to show off date features.




-Hoss

[jira] Resolved: (SOLR-1367) Provide Callback mechanism for SolrPluginUtils.docListToSolrDocumentList


 [ 
https://issues.apache.org/jira/browse/SOLR-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Grant Ingersoll resolved SOLR-1367.
---

Resolution: Fixed

Committed revision 805528.

 Provide Callback mechanism for SolrPluginUtils.docListToSolrDocumentList
 

 Key: SOLR-1367
 URL: https://issues.apache.org/jira/browse/SOLR-1367
 Project: Solr
  Issue Type: Improvement
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
 Fix For: 1.4

 Attachments: SOLR-1367.patch


 Sometimes SearchComponents need to modify the DocList.  Often times this 
 requires two loops over the (Solr)DocList: once to convert the DocList to 
 SolrDocList and then once to iterate the SolrDocList for the Search 
 Component.  This can be seen in SOLR-773, for example.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1296) Enable opening IndexReader with termInfosIndexDivisor and setting IndexWriter's termIndexInterval


[ 
https://issues.apache.org/jira/browse/SOLR-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744638#action_12744638
 ] 

Grant Ingersoll commented on SOLR-1296:
---

bq. Why would we go through the effort? IW is a public Lucene class.

Because it's not publicly exposed in Solr and exposing it just for the sake of 
testing doesn't seem wise.

 Enable opening IndexReader with termInfosIndexDivisor and setting 
 IndexWriter's termIndexInterval
 -

 Key: SOLR-1296
 URL: https://issues.apache.org/jira/browse/SOLR-1296
 Project: Solr
  Issue Type: Improvement
Affects Versions: 1.3
Reporter: Jason Rutherglen
Assignee: Grant Ingersoll
Priority: Trivial
 Fix For: 1.4

 Attachments: SOLR-1296.patch, SOLR-1296.patch, SOLR-1296.patch, 
 SOLR-1296.patch

   Original Estimate: 48h
  Remaining Estimate: 48h

 We need to enable opening an IndexReader with termInfosIndexDivisor set in 
 solrConfig.  
 We need to enable setting the termIndexInterval in SolrIndexConfig.  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Solr 1.4 Work


https://issues.apache.org/jira/secure/BrowseVersion.jspa?id=12310230versionId=12313351showOpenIssuesOnly=true

Still 20ish issues to be worked on.

[jira] Updated: (SOLR-1365) Add configurable Sweetspot Similarity factory

[
https://issues.apache.org/jira/browse/SOLR-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Grant Ingersoll updated SOLR-1365:
--

Fix Version/s: (was: 1.4)
1.5

Needs tests. Not sure this will make 1.4, as we are trying to not add new
features at this point.

Add configurable Sweetspot Similarity factory
-

Key: SOLR-1365
URL: https://issues.apache.org/jira/browse/SOLR-1365
Project: Solr
Issue Type: New Feature
Affects Versions: 1.3
Reporter: Kevin Osborn
Priority: Minor
Fix For: 1.5

Attachments: SOLR-1365.patch

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1365) Add configurable Sweetspot Similarity factory


[ 
https://issues.apache.org/jira/browse/SOLR-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744643#action_12744643
 ] 

Hoss Man commented on SOLR-1365:


FWIW: if a new feature doesn't have any impact on existing users, and has good 
tests, then i say we might as well commit it for 1.4

 (If we were talking about a new feature on an existing component, then i'd be 
hesitant because of how that feature might impact existing users of that 
component -- but in this case even if it has bad performance or some small bug 
that slips through tests, people have to go out of their way to use it)

But grant's right: needs tests before it's really a subject for debate.

 Add configurable Sweetspot Similarity factory
 -

 Key: SOLR-1365
 URL: https://issues.apache.org/jira/browse/SOLR-1365
 Project: Solr
  Issue Type: New Feature
Affects Versions: 1.3
Reporter: Kevin Osborn
Priority: Minor
 Fix For: 1.5

 Attachments: SOLR-1365.patch


 This is some code that I wrote a while back.
 Normally, if you use SweetSpotSimilarity, you are going to make it do 
 something useful by extending SweetSpotSimilarity. So, instead, I made a 
 factory class and an configurable SweetSpotSimilarty. There are two classes. 
 SweetSpotSimilarityFactory reads the parameters from schema.xml. It then 
 creates an instance of VariableSweetSpotSimilarity, which is my custom 
 SweetSpotSimilarity class. In addition to the standard functions, it also 
 handles dynamic fields.
 So, in schema.xml, you could have something like this:
 similarity class=org.apache.solr.schema.SweetSpotSimilarityFactory
 bool name=useHyperbolicTftrue/bool
   float name=hyperbolicTfFactorsMin1.0/float
   float name=hyperbolicTfFactorsMax1.5/float
   float name=hyperbolicTfFactorsBase1.3/float
   float name=hyperbolicTfFactorsXOffset2.0/float
   int name=lengthNormFactorsMin1/int
   int name=lengthNormFactorsMax1/int
   float name=lengthNormFactorsSteepness0.5/float
   int name=lengthNormFactorsMin_description2/int
   int name=lengthNormFactorsMax_description9/int
   float name=lengthNormFactorsSteepness_description0.2/float
   int name=lengthNormFactorsMin_supplierDescription_*2/int
   int name=lengthNormFactorsMax_supplierDescription_*7/int
   float 
 name=lengthNormFactorsSteepness_supplierDescription_*0.4/float
  /similarity
 So, now everything is in a config file instead of having to create your own 
 subclass.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1296) Enable opening IndexReader with termInfosIndexDivisor and setting IndexWriter's termIndexInterval


[ 
https://issues.apache.org/jira/browse/SOLR-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744642#action_12744642
 ] 

Jason Rutherglen commented on SOLR-1296:


bq. Because it's not publicly exposed in Solr and exposing it just for the sake 
of testing doesn't seem wise.

Can you describe the worst case scenario you imagine will happen if IndexWriter 
is exposed?

 Enable opening IndexReader with termInfosIndexDivisor and setting 
 IndexWriter's termIndexInterval
 -

 Key: SOLR-1296
 URL: https://issues.apache.org/jira/browse/SOLR-1296
 Project: Solr
  Issue Type: Improvement
Affects Versions: 1.3
Reporter: Jason Rutherglen
Assignee: Grant Ingersoll
Priority: Trivial
 Fix For: 1.4

 Attachments: SOLR-1296.patch, SOLR-1296.patch, SOLR-1296.patch, 
 SOLR-1296.patch

   Original Estimate: 48h
  Remaining Estimate: 48h

 We need to enable opening an IndexReader with termInfosIndexDivisor set in 
 solrConfig.  
 We need to enable setting the termIndexInterval in SolrIndexConfig.  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Can synonyms be defined in a multi-valued field or a database?

2009-08-18 Thread Lajos


Kelly,

We just had this problem. We implemented a custom SynonymFilterFactory 
that accessed a Spring context and from that a list of synonyms from the 
database via Hibernate. It was trivial to do and works quite well. Note 
that you have to extend BaseTokenFilterFactory; you cannot just extend 
SynonymFilterFactory.


Lajos


Kelly Taylor wrote:

I need the ability to remotely administer synonyms for each of my Solr
standalone instances. It seems that my only option is that of uploading a
file per instance, restarting the respective Solr instance(s), and then
rebuilding my indexes. 


Can synonyms be defined in a multi-valued field or a database in place of a
file? Or can synonyms be administered in any way other than editing a file? 


-Kelly





No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.392 / Virus Database: 270.13.59/2310 - Release Date: 08/17/09 18:04:00

[jira] Commented: (SOLR-1296) Enable opening IndexReader with termInfosIndexDivisor and setting IndexWriter's termIndexInterval


[ 
https://issues.apache.org/jira/browse/SOLR-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744650#action_12744650
 ] 

Grant Ingersoll commented on SOLR-1296:
---

bq. Can you describe the worst case scenario you imagine will happen if 
IndexWriter is exposed?

Sure, someone who thinks they know what they are doing closes the IW when it 
shouldn't be closed causing exceptions, etc and emails to solr-user, etc. and 
wasting the communities time.  However, the impetus is not on me to defend why 
it shouldn't be exposed, it's on you to show why it is proper to take something 
that is currently private and make it public just to pass a test.  If it needs 
to be public for other use cases, fine, but generally speaking, I don't think 
variables, etc. should be made public just for testing purposes.  That's bad 
OOD.

 Enable opening IndexReader with termInfosIndexDivisor and setting 
 IndexWriter's termIndexInterval
 -

 Key: SOLR-1296
 URL: https://issues.apache.org/jira/browse/SOLR-1296
 Project: Solr
  Issue Type: Improvement
Affects Versions: 1.3
Reporter: Jason Rutherglen
Assignee: Grant Ingersoll
Priority: Trivial
 Fix For: 1.4

 Attachments: SOLR-1296.patch, SOLR-1296.patch, SOLR-1296.patch, 
 SOLR-1296.patch

   Original Estimate: 48h
  Remaining Estimate: 48h

 We need to enable opening an IndexReader with termInfosIndexDivisor set in 
 solrConfig.  
 We need to enable setting the termIndexInterval in SolrIndexConfig.  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-1143) Return partial results when a connection to a shard is refused

2009-08-18 Thread Martijn van Groningen (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Martijn van Groningen updated SOLR-1143:

Attachment: SOLR-1143-3.patch

You are right Grant. I guess I forgot about the request handler defaults when I
was creating this patch...
I have removed the possibility to configure partial results via the
_return-partial-results_ property in the latest patch. The request handler
defaults can perfectly configure partial results to be enabled by default.

Return partial results when a connection to a shard is refused
--

Key: SOLR-1143
URL: https://issues.apache.org/jira/browse/SOLR-1143
Project: Solr
Issue Type: Improvement
Components: search
Reporter: Nicolas Dessaigne
Fix For: 1.4

Attachments: SOLR-1143-2.patch, SOLR-1143-3.patch, SOLR-1143.patch

If any shard is down in a distributed search, a ConnectException it thrown.
Here's a little patch that change this behaviour: if we can't connect to a
shard (ConnectException), we get partial results from the active shards. As
for TimeOut parameter (https://issues.apache.org/jira/browse/SOLR-502), we
set the parameter partialResults at true.
This patch also adresses a problem expressed in the mailing list about a year
ago
(http://www.nabble.com/partialResults,-distributed-search---SOLR-502-td19002610.html)
We have a use case that needs this behaviour and we would like to know your
thougths about such a behaviour? Should it be the default behaviour for
distributed search?

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1296) Enable opening IndexReader with termInfosIndexDivisor and setting IndexWriter's termIndexInterval


[ 
https://issues.apache.org/jira/browse/SOLR-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744679#action_12744679
 ] 

Jason Rutherglen commented on SOLR-1296:


For a test I agree it's not worth exposing IW publicly however
there should be a simple way to access it as a package protected
variable?

A great example of a public Lucene API being exposed from Solr
that can easily break the system is getWrappedReader. IR is as
canonical to Lucene as IW. And calling close on IR will also
cause numerous errors for users. Why is it public, it's only
used internally to Solr? 

The Solr policy as it's being described isn't making sense to me.

An answer to the second question?

{quote} bq. do we really need solrconfig-termindex.xml

We probably don't want all the tests to have different behavior.
{quote}



 Enable opening IndexReader with termInfosIndexDivisor and setting 
 IndexWriter's termIndexInterval
 -

 Key: SOLR-1296
 URL: https://issues.apache.org/jira/browse/SOLR-1296
 Project: Solr
  Issue Type: Improvement
Affects Versions: 1.3
Reporter: Jason Rutherglen
Assignee: Grant Ingersoll
Priority: Trivial
 Fix For: 1.4

 Attachments: SOLR-1296.patch, SOLR-1296.patch, SOLR-1296.patch, 
 SOLR-1296.patch

   Original Estimate: 48h
  Remaining Estimate: 48h

 We need to enable opening an IndexReader with termInfosIndexDivisor set in 
 solrConfig.  
 We need to enable setting the termIndexInterval in SolrIndexConfig.  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1365) Add configurable Sweetspot Similarity factory

2009-08-18 Thread Kevin Osborn (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744682#action_12744682
]

Kevin Osborn commented on SOLR-1365:

Thanks for the comments. I'll make the changes for Erik's suggestions and come
up with some tests. If it gets into 1.4, great. If not, then it is not a huge
deal since this is already production code for us. But, if it could be put into
the main code base, then even better.

Add configurable Sweetspot Similarity factory
-

Key: SOLR-1365
URL: https://issues.apache.org/jira/browse/SOLR-1365
Project: Solr
Issue Type: New Feature
Affects Versions: 1.3
Reporter: Kevin Osborn
Priority: Minor
Fix For: 1.5

Attachments: SOLR-1365.patch

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-705) Distributed search should optionally return docID-shard map

2009-08-18 Thread Ryan McKinley (JIRA)


 [ 
https://issues.apache.org/jira/browse/SOLR-705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan McKinley updated SOLR-705:
---

Fix Version/s: (was: 1.4)
   1.5

Moving this issue to 1.5 so that the details could be worked out with less 
haste.

http://www.lucidimagination.com/search/document/1f2e56f58162679d/response_writers_and_doclists

 Distributed search should optionally return docID-shard map
 

 Key: SOLR-705
 URL: https://issues.apache.org/jira/browse/SOLR-705
 Project: Solr
  Issue Type: Improvement
Affects Versions: 1.3
 Environment: all
Reporter: Brian Whitman
Assignee: Ryan McKinley
 Fix For: 1.5

 Attachments: SOLR-705.patch, SOLR-705.patch, SOLR-705.patch, 
 SOLR-705.patch, SOLR-705.patch, SOLR-705.patch


 SOLR-303 queries with shards parameters set need to return the dociD-shard 
 mapping in the response. Without it, updating/deleting documents when the # 
 of shards is variable is hard. We currently set this with a special 
 requestHandler that filters /update and inserts the shard as a field in the 
 index but it would be better if the shard location came back in the query 
 response outside of the index.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1296) Enable opening IndexReader with termInfosIndexDivisor and setting IndexWriter's termIndexInterval

2009-08-18 Thread Mark Miller (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744686#action_12744686
 ] 

Mark Miller commented on SOLR-1296:
---

I'm not against exposing something package private for tests - anyone that 
jumps the fence to use that should know what they are getting themselves into.

 Enable opening IndexReader with termInfosIndexDivisor and setting 
 IndexWriter's termIndexInterval
 -

 Key: SOLR-1296
 URL: https://issues.apache.org/jira/browse/SOLR-1296
 Project: Solr
  Issue Type: Improvement
Affects Versions: 1.3
Reporter: Jason Rutherglen
Assignee: Grant Ingersoll
Priority: Trivial
 Fix For: 1.4

 Attachments: SOLR-1296.patch, SOLR-1296.patch, SOLR-1296.patch, 
 SOLR-1296.patch

   Original Estimate: 48h
  Remaining Estimate: 48h

 We need to enable opening an IndexReader with termInfosIndexDivisor set in 
 solrConfig.  
 We need to enable setting the termIndexInterval in SolrIndexConfig.  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Updating Lucene/Solr home pages with news of the Solr book

2009-08-18 Thread David Smiley @MITRE.org


Hello Solr devs.  I'd like to see news of my book Solr 1.4 Enterprise Search
Server placed on the Solr home page.  Yonik suggested that Lucene's home
page would also be suitable.  The more people that buy the book, the more
that Apache Software Foundation is supported (5% royalties).

The link to PACKT should be:
http://www.packtpub.com/solr-1-4-enterprise-search-server?utm_source=http%3A%20%2F%2Flucene.apache.org%2Fsolr%2Futm_medium=sponsutm_content=podutm_campa%20ign=mdb_000275

(yes it's kinda long; it's used to track the link click-through).  

You can also see an image on PACKT's site.  You can click through to a
larger one if desired.

I'm not sure if it would be appropriate for me to write the news blurb since
I'm not a Lucene/Solr committer but I can if you'd like me to.

~ David Smiley
-- 
View this message in context: 
http://www.nabble.com/Updating-Lucene-Solr-home-pages-with-news-of-the-Solr-book-tp25032908p25032908.html
Sent from the Solr - Dev mailing list archive at Nabble.com.

Re: Updating Lucene/Solr home pages with news of the Solr book

2009-08-18 Thread Erik Hatcher


David,

Best way to make this happen is to submit patches to the desired  
projects websites (and of course self add the book to the wiki spots  
too).


And congrats on the book!  I know it's a lot of work, more than one  
expects going into it.  And the never ending Solr 1.4 release hasn't  
helped either.


Erik

On Aug 18, 2009, at 4:30 PM, David Smiley @MITRE.org wrote:



Hello Solr devs.  I'd like to see news of my book Solr 1.4  
Enterprise Search
Server placed on the Solr home page.  Yonik suggested that Lucene's  
home
page would also be suitable.  The more people that buy the book, the  
more

that Apache Software Foundation is supported (5% royalties).

The link to PACKT should be:
http://www.packtpub.com/solr-1-4-enterprise-search-server?utm_source=http%3A%20%2F%2Flucene.apache.org%2Fsolr%2Futm_medium=sponsutm_content=podutm_campa%20ign=mdb_000275

(yes it's kinda long; it's used to track the link click-through).

You can also see an image on PACKT's site.  You can click through to a
larger one if desired.

I'm not sure if it would be appropriate for me to write the news  
blurb since

I'm not a Lucene/Solr committer but I can if you'd like me to.

~ David Smiley
--
View this message in context: 
http://www.nabble.com/Updating-Lucene-Solr-home-pages-with-news-of-the-Solr-book-tp25032908p25032908.html
Sent from the Solr - Dev mailing list archive at Nabble.com.

[jira] Created: (SOLR-1371) LukeRequestHandler/schema.jsp errors if schema has no uniqueKey field

LukeRequestHandler/schema.jsp errors if schema has no uniqueKey field
-

 Key: SOLR-1371
 URL: https://issues.apache.org/jira/browse/SOLR-1371
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 1.3
Reporter: Hoss Man


if a schema doesn't have a uniqueKey field specified, teh schema explorer won't 
work, and logs this exception...

{code}
SEVERE: java.lang.NullPointerException
at 
org.apache.solr.handler.admin.LukeRequestHandler.getSchemaInfo(LukeRequestHandler.java:373)
at 
org.apache.solr.handler.admin.LukeRequestHandler.handleRequestBody(LukeRequestHandler.java:133)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1299)
at 
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241)
at 
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089)
{code}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1371) LukeRequestHandler/schema.jsp errors if schema has no uniqueKey field


[ 
https://issues.apache.org/jira/browse/SOLR-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744710#action_12744710
 ] 

Hoss Man commented on SOLR-1371:


the fix seems pretty trivial, but i'd like to have a nice robust testcase of a 
minimal schema that we can have to help prevent little glitches like this in 
the future

 LukeRequestHandler/schema.jsp errors if schema has no uniqueKey field
 -

 Key: SOLR-1371
 URL: https://issues.apache.org/jira/browse/SOLR-1371
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 1.3
Reporter: Hoss Man

 if a schema doesn't have a uniqueKey field specified, teh schema explorer 
 won't work, and logs this exception...
 {code}
 SEVERE: java.lang.NullPointerException
 at 
 org.apache.solr.handler.admin.LukeRequestHandler.getSchemaInfo(LukeRequestHandler.java:373)
 at 
 org.apache.solr.handler.admin.LukeRequestHandler.handleRequestBody(LukeRequestHandler.java:133)
 at 
 org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
 at org.apache.solr.core.SolrCore.execute(SolrCore.java:1299)
 at 
 org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338)
 at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241)
 at 
 org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089)
 {code}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-788) MoreLikeThis should support distributed search

2009-08-18 Thread Matthew Woytowitz (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744734#action_12744734
 ] 

Matthew Woytowitz commented on SOLR-788:


It's on the top of the patch.  772437

--- org/apache/solr/handler/MoreLikeThisHandler.java(revision 772437)
+++ org/apache/solr/handler/MoreLikeThisHandler.java(working copy)



Matt Woytowitz
Software Enginneer
ManTech International Corporation
Phone:  (703) 674-3674
Email: matthew.woytow...@mantech.com




 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
 Attachments: MoreLikeThisComponentTest.patch, 
 SolrMoreLikeThisPatch.txt


 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] Commented: (SOLR-1367) Provide Callback mechanism for SolrPluginUtils.docListToSolrDocumentList


[ 
https://issues.apache.org/jira/browse/SOLR-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744748#action_12744748
 ] 

Yonik Seeley commented on SOLR-1367:


I'm puzzled wondering why this is an improvement.

New:
{code}
SolrDocumentList sdocs = docListToSolrDocumentList(dlist,..., 
  new SolrDocumentModifier() {
void process(SolrDocument doc) {
  doc.add(foo,1);
}
  }, 
...);
{code}

Old:
{code}
SolrDocumentList sdocs = docListToSolrDocumentList(dlist,...,...);
for (SolrDocument doc : sdocs) {
  d.add(foo,1);
}
{code}


 Provide Callback mechanism for SolrPluginUtils.docListToSolrDocumentList
 

 Key: SOLR-1367
 URL: https://issues.apache.org/jira/browse/SOLR-1367
 Project: Solr
  Issue Type: Improvement
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
 Fix For: 1.4

 Attachments: SOLR-1367.patch


 Sometimes SearchComponents need to modify the DocList.  Often times this 
 requires two loops over the (Solr)DocList: once to convert the DocList to 
 SolrDocList and then once to iterate the SolrDocList for the Search 
 Component.  This can be seen in SOLR-773, for example.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-1371) LukeRequestHandler/schema.jsp errors if schema has no uniqueKey field


 [ 
https://issues.apache.org/jira/browse/SOLR-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hoss Man updated SOLR-1371:
---

Attachment: SOLR-1371.patch

patch that fixes the LukeRequestHandler, and adds a new MinimalSchemaTest to 
serve as a place to more tests like this in the future. 

In an attempt to proactively spot problems like this, it uses the catchall 
solrconfig.xml that many other test use and does some introspection to try and 
hit any request handler it can find with trivial input to make sure it doesn't 
barf.

to make this work, i changed QueryElevationComponentTest to use a new 
solrconfig.xml (and in the process discovered a bug in the test where it wasn't 
hitting hte request handler it thought it was)

any objects

 LukeRequestHandler/schema.jsp errors if schema has no uniqueKey field
 -

 Key: SOLR-1371
 URL: https://issues.apache.org/jira/browse/SOLR-1371
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 1.3
Reporter: Hoss Man
 Attachments: SOLR-1371.patch


 if a schema doesn't have a uniqueKey field specified, teh schema explorer 
 won't work, and logs this exception...
 {code}
 SEVERE: java.lang.NullPointerException
 at 
 org.apache.solr.handler.admin.LukeRequestHandler.getSchemaInfo(LukeRequestHandler.java:373)
 at 
 org.apache.solr.handler.admin.LukeRequestHandler.handleRequestBody(LukeRequestHandler.java:133)
 at 
 org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
 at org.apache.solr.core.SolrCore.execute(SolrCore.java:1299)
 at 
 org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338)
 at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241)
 at 
 org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089)
 {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-1371) LukeRequestHandler/schema.jsp errors if schema has no uniqueKey field


 [ 
https://issues.apache.org/jira/browse/SOLR-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hoss Man updated SOLR-1371:
---

Fix Version/s: 1.4
 Assignee: Hoss Man

any objections to me committing this before 1.4? 

(by this i mean the test changes, i can't imagine anyone would object to me 
fixing the bug in LukeRequestHandler)

 LukeRequestHandler/schema.jsp errors if schema has no uniqueKey field
 -

 Key: SOLR-1371
 URL: https://issues.apache.org/jira/browse/SOLR-1371
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 1.3
Reporter: Hoss Man
Assignee: Hoss Man
 Fix For: 1.4

 Attachments: SOLR-1371.patch


 if a schema doesn't have a uniqueKey field specified, teh schema explorer 
 won't work, and logs this exception...
 {code}
 SEVERE: java.lang.NullPointerException
 at 
 org.apache.solr.handler.admin.LukeRequestHandler.getSchemaInfo(LukeRequestHandler.java:373)
 at 
 org.apache.solr.handler.admin.LukeRequestHandler.handleRequestBody(LukeRequestHandler.java:133)
 at 
 org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
 at org.apache.solr.core.SolrCore.execute(SolrCore.java:1299)
 at 
 org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338)
 at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241)
 at 
 org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089)
 {code}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [jira] Updated: (SOLR-1067) QueryParsing.parseFunction uses Singleton Core (SolrCore.getSolrCore())


:  : I think we've done everything reasonable for 1.4, moving the rest to 1.5
: 
:  from a project management / CHANGES.txt clrity stanpoint, it seems like we
:  should be creating new issues for any parts of issues like this one that
:  we're pushing off post 1.4 ... otherwise 1.4's CHANGES.txt has a list of
:  bugs that were fixed, but when you look up the bug details it says it's
:  still open.  and down the road 1.X will say it fixed hte exact same but.
: 
: I guess this is something I'd avoid adding to CHANGES.txt all together
: - it's really pretty internal stuff.

That's a slippery slope dude ... even if something is in the internals it 
can have behavioral effects on people who don't touch it directly (not to 
mention plugin developers who might actually be touching it directly)

I think just about everything should be in CHANGES.txt ... if someone 
upgrades and gets a weird bug, the first place (we want people) to look 
for explanations is CHANGES.txt ... in an ideal world it lets people post 
questions like when i upgraded from 1.3 to 1.4 i started getting errors 
with XYZ, i noticed CHANGES.txt mentions ABC and it occured to me that i 
use XYZ w/ABC so maybe that's causing this bug?

leaving stuff out of CHANGES just because it's an internal change seems 
like it just makes everybodies life harder when bugs pop up.


-Hoss

[jira] Commented: (SOLR-1354) Pass HTTP request parameters through to XSL scripts

[
https://issues.apache.org/jira/browse/SOLR-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744774#action_12744774
]

Hoss Man commented on SOLR-1354:

Lance: the topic of XSL params came up once upon a time, and before anyone ever
got around to implementing it, someone pointed out that using echoParams you
could get all of the params into the XML so that the template had access to
them.

you've already written the code to convert params to xsl:params ... using
echoParams still seems like it's more generally useful, because it can work
with any param, and allows for multi-valued params as well (giving the tempalte
the power to use the first, or all).

Is there any significant advantage you see to adding xsl:param support that
echoParams *can't* handle?

Pass HTTP request parameters through to XSL scripts
---

Key: SOLR-1354
URL: https://issues.apache.org/jira/browse/SOLR-1354
Project: Solr
Issue Type: New Feature
Components: search
Environment: Any JDK from 1.5 onward. Any OS. Uses standard XSLTC
'compiled'-only version of Apache Xalan distributed with the JRE.
Reporter: Lance Norskog
Priority: Minor
Attachments: rss2.patch

It is not possible to create a standard web application with the Solr
distribution without coding in XSL, Ruby, HTML/Javascript etc.
This patch is an experiment that allows you to configure an RSS 2.0 feed
through HTTP parameters. To do this, it supplies:
1) a change to XSLTWriter.java to pass an HTTP parameter named 'tr.name'
through as an XSL parameter called 'name'. The XSL script must then declare
'name' as a global parameter.
2) example/solr/conf/xslt/rss2.xsl - a mostly complete implementation of RSS
2.0.
3) a sample requestHandler in example/solr/conf/solrconfig.xml which
configures solr/rss2 as an RSS feed for the sample electronics store in
example/solr. This requestHandler supplies all parameters for the RSS feed.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Updating Lucene/Solr home pages with news of the Solr book


: Best way to make this happen is to submit patches to the desired projects
: websites (and of course self add the book to the wiki spots too).

By which Erik means patches to the website *sources* (not patches to the 
generated HTML).  Both Solr and the main lucene site use forrest to 
generate the sites...

Solr website...
http://wiki.apache.org/solr/Website_Update_HOWTO
http://svn.apache.org/repos/asf/lucene/solr/trunk/src/site/

Main Lucene website...
http://svn.apache.org/repos/asf/lucene/site/

You might want to take a look at how LIA got added to the LUcene-Java left 
nav and submit a path that does hte same thing for Solr's site...
http://svn.apache.org/viewvc?view=revrevision=751729




-Hoss

[jira] Commented: (SOLR-1367) Provide Callback mechanism for SolrPluginUtils.docListToSolrDocumentList


[ 
https://issues.apache.org/jira/browse/SOLR-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744784#action_12744784
 ] 

Grant Ingersoll commented on SOLR-1367:
---

B/c docListToSolrDocList also requires looping over the DocList.  So, in the 
old case, you've iterated the DocList twice.  In the new way, you only iterated 
it once.

 Provide Callback mechanism for SolrPluginUtils.docListToSolrDocumentList
 

 Key: SOLR-1367
 URL: https://issues.apache.org/jira/browse/SOLR-1367
 Project: Solr
  Issue Type: Improvement
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
 Fix For: 1.4

 Attachments: SOLR-1367.patch


 Sometimes SearchComponents need to modify the DocList.  Often times this 
 requires two loops over the (Solr)DocList: once to convert the DocList to 
 SolrDocList and then once to iterate the SolrDocList for the Search 
 Component.  This can be seen in SOLR-773, for example.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1367) Provide Callback mechanism for SolrPluginUtils.docListToSolrDocumentList


[ 
https://issues.apache.org/jira/browse/SOLR-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744788#action_12744788
 ] 

Yonik Seeley commented on SOLR-1367:


It seems in this case that iteration is more straight-forward and easier to 
understand, and offers the same performance.

 Provide Callback mechanism for SolrPluginUtils.docListToSolrDocumentList
 

 Key: SOLR-1367
 URL: https://issues.apache.org/jira/browse/SOLR-1367
 Project: Solr
  Issue Type: Improvement
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
 Fix For: 1.4

 Attachments: SOLR-1367.patch


 Sometimes SearchComponents need to modify the DocList.  Often times this 
 requires two loops over the (Solr)DocList: once to convert the DocList to 
 SolrDocList and then once to iterate the SolrDocList for the Search 
 Component.  This can be seen in SOLR-773, for example.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1368) ms() function for date math


[ 
https://issues.apache.org/jira/browse/SOLR-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744810#action_12744810
 ] 

Hoss Man commented on SOLR-1368:


bq. ms(field) a date field (needs to be a trie-date variant that has 
milliseconds available)

why?

if it's legal to call ms on a rounded date (ie: NOW/SECOND) then why shouldn't 
it be legal to use a trie field with coarse precision?

 ms() function for date math
 ---

 Key: SOLR-1368
 URL: https://issues.apache.org/jira/browse/SOLR-1368
 Project: Solr
  Issue Type: New Feature
Reporter: Yonik Seeley
Assignee: Yonik Seeley
 Fix For: 1.4

 Attachments: SOLR-1368.patch


 ms (milliseconds) function to use dates in function queries

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1368) ms() function for date math


[ 
https://issues.apache.org/jira/browse/SOLR-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744814#action_12744814
 ] 

Yonik Seeley commented on SOLR-1368:


bq. if it's legal to call ms on a rounded date (ie: NOW/SECOND) then why 
shouldn't it be legal to use a trie field with coarse precision?

It should (and I do have plans for that in the future).  What I meant by that 
is the newer trie based fields are the only ones you can get milliseconds from 
(regardless of precision) as opposed to a date string.  It's not practical to 
convert date strings to milliseconds/seconds on the fly from the fieldcache.  
Perhaps we should throw an exception rather than silently using ord for those 
string-date fields though?


 ms() function for date math
 ---

 Key: SOLR-1368
 URL: https://issues.apache.org/jira/browse/SOLR-1368
 Project: Solr
  Issue Type: New Feature
Reporter: Yonik Seeley
Assignee: Yonik Seeley
 Fix For: 1.4

 Attachments: SOLR-1368.patch


 ms (milliseconds) function to use dates in function queries

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: date functions and floats

: nice not to have to think about this on the client side.  Perhaps I am just
: missing something.  In other words, do we support Lucene's DateTools
: Resolution capabilities?

currently the only way to do something like this with DateField is for the 
client to specify a rounding operation when indexing...
2009-12-14T01:01:01.004Z/DAY

...there was some discussion about adding options to the DateField that 
would allow rounding options to be specified in shcema.xml, but no one 
ever worked up a patch ... 

https://issues.apache.org/jira/browse/SOLR-741


-Hoss

[jira] Commented: (SOLR-1367) Provide Callback mechanism for SolrPluginUtils.docListToSolrDocumentList

[
https://issues.apache.org/jira/browse/SOLR-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744818#action_12744818
]

Grant Ingersoll commented on SOLR-1367:
---

What's hard to understand about a callback mechanism? It's akin to FileFilter
for File.listFiles or similar things.

Also, why would two loops over the same list be the same performance as one? I
suppose in the rows=10 or so case, it is in the noise, but, but if someone were
getting deeper results than say 10, the Modifier approach would be faster.
Now multiply the need to do this for every query and I think it would add up.

The whole use case is very much a special case. Most people in most situations
don't need to do this. But when you do need to do it, you do it all the time
and you want it to be fast. That being said, people can implement it
themselves. I just figured since the docListToSolrDocList method was already
there, it would be a time saver.

Provide Callback mechanism for SolrPluginUtils.docListToSolrDocumentList

Key: SOLR-1367
URL: https://issues.apache.org/jira/browse/SOLR-1367
Project: Solr
Issue Type: Improvement
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
Fix For: 1.4

Attachments: SOLR-1367.patch

Sometimes SearchComponents need to modify the DocList. Often times this
requires two loops over the (Solr)DocList: once to convert the DocList to
SolrDocList and then once to iterate the SolrDocList for the Search
Component. This can be seen in SOLR-773, for example.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1367) Provide Callback mechanism for SolrPluginUtils.docListToSolrDocumentList

[
https://issues.apache.org/jira/browse/SOLR-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744826#action_12744826
]

Yonik Seeley commented on SOLR-1367:

bq. What's hard to understand about a callback mechanism?

Callbacks are useful when you need to execute your own snippet of code in a
different context - that's not the case here.

bq. Also, why would two loops over the same list be the same performance as one?

Because the iteration part is irrelevant compared to what else is done during
the iteration. Iteration can be as simple as a pointer dereference. The
callback approach has null pointer check whether to invoke the modifier or
not... and that gets done even if no modifier will be used (but that will also
be in the noise).

bq. Now multiply the need to do this for every query and I think it would add
up.

It won't - it won't even be measurable.

bq. The whole use case is very much a special case. Most people in most
situations don't need to do this.

Which would seem to argue against adding code to try and do it.

That said, docListToSolrDocList isn't even used in Solr anywhere, so I don't
care too much - it can be deprecated/removed later. Solr itself shouldn't use
this method since it's not streamable. Allowing custom modifications while
preserving streamability *does* call for callbacks... but not in 1.4

Provide Callback mechanism for SolrPluginUtils.docListToSolrDocumentList

Key: SOLR-1367
URL: https://issues.apache.org/jira/browse/SOLR-1367
Project: Solr
Issue Type: Improvement
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
Fix For: 1.4

Attachments: SOLR-1367.patch

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: svn commit: r804477 - in /lucene/solr/trunk/example/exampledocs: hd.xml mem.xml sd500.xml vidcard.xml

2009-08-18 Thread Yonik Seeley

On Tue, Aug 18, 2009 at 2:30 PM, Chris
Hostetterhossman_luc...@fucit.org wrote:
 We have other date fields we can use to show off date features.

OK - any suggestions on what field to use for our example docs?  It
could either be a dynamic field or a normal one... but I'm drawing a
creative blank for the name.

-Yonik
http://www.lucidimagination.com

[jira] Updated: (SOLR-1368) ms() function for date math


 [ 
https://issues.apache.org/jira/browse/SOLR-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yonik Seeley updated SOLR-1368:
---

Attachment: SOLR-1368.patch

Attaching new patch with tests.
This now throws an exception if ms() is used on string-based date fields (as 
opposed to numeric/trie).

 ms() function for date math
 ---

 Key: SOLR-1368
 URL: https://issues.apache.org/jira/browse/SOLR-1368
 Project: Solr
  Issue Type: New Feature
Reporter: Yonik Seeley
Assignee: Yonik Seeley
 Fix For: 1.4

 Attachments: SOLR-1368.patch, SOLR-1368.patch


 ms (milliseconds) function to use dates in function queries

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-630) Spellchecker should not be case-sensitive and should be stopwords-aware

2009-08-18 Thread Alex Baranov (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744860#action_12744860
]

Alex Baranov commented on SOLR-630:
---

I would propose to close this bug.

1) of-oft
Whether stop words are omitted or not depends on:
a. If q parameter is used, then queryAnalyzerFieldType parameter is
used to determine the analyzer for the query. If queryAnalyzerFieldType is
not specified, then WhitespaceTokenizer is used.
b. If spellcheck.q parameter is used, then query analyzer of the
spellchecker field is used.

2) America-Americaa, america-[none]
I couldn't reproduce that. The results are the same as for America as for
america. However, spellchecker is really case-sensitive. For example, if
there is AmErIcAa in the spellchecker index then this suggestion won't appear
neither for America nor for america, but would appear for AmErIcA.
The reason, why America-Americaa, america-Americaa lies in the n-gram
method which is used in lucene spellchecker: for America and america the same
grams are defined, the only difference is startN gram. Actually there is
still might be a difference in the results: the method works so that it boosts
the relevance of the suggestion if the first N letters of it are the same as in
the word under spellcheck.

I'm not sure whether case-sensitiveness(is it a word?) is a bug or not.
Anyway, finding suggestions as well as creating the index for spellchecker is
delegated to the Lucene SpellChecker, so this is Lucene issue, not Solr.

P.S. I believe that one can avoid case-sensitive issue by configuring properly
the analyzers (e.g. for the spellchecker field).

Spellchecker should not be case-sensitive and should be stopwords-aware
---

Key: SOLR-630
URL: https://issues.apache.org/jira/browse/SOLR-630
Project: Solr
Issue Type: Bug
Components: spellchecker
Reporter: Otis Gospodnetic
Priority: Minor
Fix For: 1.5

Here are 2 more bugs:
1)
Search for:
united states of America
Suggests:
united states oft America
It looks like the SC doesn't check stopwords, and of is a stopword. Thus,
it does not exist in the index,
but oft does, so SC suggests oft and thinks of is misspelled. I think
the SC component should check the list of
stopwords, too, no?
2)
Search for:
united states of America
Suggests:
united states oftAmericaa
The of-oft is described above. But note how SC suggested America-Americaa,
but it didn't do that for america.
This looks like case-sensitivity problem. Shouldn't the SC be
case-insensitive?
I can't produce a patch now (no src handy), so I'm hoping Grant or somebody
else can do it based on this report.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1315) new replication command needed to force a backup when there is no committed index data

2009-08-18 Thread Jay (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-1315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744870#action_12744870
]

Jay commented on SOLR-1315:
---

tried it, and it looks good.

new replication command needed to force a backup when there is no committed
index data
--

Key: SOLR-1315
URL: https://issues.apache.org/jira/browse/SOLR-1315
Project: Solr
Issue Type: New Feature
Components: replication (java)
Affects Versions: 1.4
Environment: Mac OS
Reporter: Jay
Assignee: Noble Paul
Priority: Minor
Fix For: 1.4

Attachments: SOLR-1315.patch

Original Estimate: 5h
Remaining Estimate: 5h

Here is an email describing the problem, and a possible solution.
I agree. I think both options could be useful - perhaps a 'forceBackup' as
well? Documentation would take care of the rest. Have you added this info to
the wiki yet?
--
- Mark
http://www.lucidimagination.com
On Thu, Jul 23, 2009 at 12:56 PM, solr jay solr...@gmail.com wrote:
Hi,

I noticed that the backup request

http://master_host:port/solr/replication?command=backup
http://master_host/solr/replication?command=backup
- Hide quoted text -

works only if there are committed index data, i.e.
core.getDeletionPolicy().getLatestCommit() is not null. Otherwise, no
backup
is created. It sounds logical because if nothing has been committed since
your last backup, it doesn't help much to do a new backup. However,
consider
this scenario:

1. a backup process is scheduled at 1:00AM every Monday
2. just before 1:00AM, the system is shutdown (for whatever reason), and
then restarts
3. No index is committed before 1:00AM
4. at 1:00AM, backup process starts and no committed index is found, and
therefore no backup (until next week)

The probability of this scenario is probably small, but it still could
happen, and it seems to me that if I want to backup index, a backup should
be created whether there are new committed index or not.

Your thoughts?

Thanks,

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1335) load core properties from a properties file

2009-08-18 Thread Noble Paul (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744882#action_12744882
]

Noble Paul commented on SOLR-1335:
--

bq.I also contest your claim that they are alwasy hardcoded for single cores
... we've been making definite progress down a path of encouraging people to
use solr.xml even for single core setups, as you say..

Are we going to do thiat in 1.4 i.e solr.xml for single cores? But this
properties file is a critical feature for our ops to deploy solr with
replication feature. (The master server is only known at deploy time).
currently we are shipping four different solrconfig.xml files

I am not really worried about the specifics of how we implement this. My
requirements are pretty simple
* A core should be able to load properties from a properties file (any file
name, any loaction is OK)
* There should be one sensible default for that file name and location , just
the way we have for schema and solrconfig

What is your preference of doing this?

load core properties from a properties file
---

Key: SOLR-1335
URL: https://issues.apache.org/jira/browse/SOLR-1335
Project: Solr
Issue Type: New Feature
Reporter: Noble Paul
Assignee: Noble Paul
Fix For: 1.4

Attachments: SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-1275) Add expungeDeletes to DirectUpdateHandler2