date:20080710


[ 
https://issues.apache.org/jira/browse/SOLR-501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12612712#action_12612712
 ] 

Yonik Seeley commented on SOLR-501:
---

bq. Any reason not to default the jsp pages to UTF-8?

We do want to default to UTF8, but we still sort of support Tomcat 5.5 with 
this release, which is only up to servlet spec 2.4 .  The comment suggests this 
API call suggests this is new for 2.5?

> /admin/analysis.jsp does not decode input string as UTF-8 sequence.
> ---
>
> Key: SOLR-501
> URL: https://issues.apache.org/jira/browse/SOLR-501
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
> Environment: Tomcat6.0
>Reporter: Hiroaki Kawai
>Assignee: Ryan McKinley
> Fix For: 1.3
>
> Attachments: header.jsp.patch
>
>
> In servlet2.5, we should call 
> HttpRequestServlet.setCharacterEncoding("UTF-8") to get a UTF-8 character 
> sequence via request.getParameter() in JSP.

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

[jira] Updated: (SOLR-501) /admin/analysis.jsp does not decode input string as UTF-8 sequence.


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

Ryan McKinley updated SOLR-501:
---

Fix Version/s: 1.3

> /admin/analysis.jsp does not decode input string as UTF-8 sequence.
> ---
>
> Key: SOLR-501
> URL: https://issues.apache.org/jira/browse/SOLR-501
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
> Environment: Tomcat6.0
>Reporter: Hiroaki Kawai
>Assignee: Ryan McKinley
> Fix For: 1.3
>
> Attachments: header.jsp.patch
>
>
> In servlet2.5, we should call 
> HttpRequestServlet.setCharacterEncoding("UTF-8") to get a UTF-8 character 
> sequence via request.getParameter() in JSP.

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

[jira] Assigned: (SOLR-501) /admin/analysis.jsp does not decode input string as UTF-8 sequence.


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

Ryan McKinley reassigned SOLR-501:
--

Assignee: Ryan McKinley

> /admin/analysis.jsp does not decode input string as UTF-8 sequence.
> ---
>
> Key: SOLR-501
> URL: https://issues.apache.org/jira/browse/SOLR-501
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
> Environment: Tomcat6.0
>Reporter: Hiroaki Kawai
>Assignee: Ryan McKinley
> Fix For: 1.3
>
> Attachments: header.jsp.patch
>
>
> In servlet2.5, we should call 
> HttpRequestServlet.setCharacterEncoding("UTF-8") to get a UTF-8 character 
> sequence via request.getParameter() in JSP.

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

[jira] Commented: (SOLR-501) /admin/analysis.jsp does not decode input string as UTF-8 sequence.


[ 
https://issues.apache.org/jira/browse/SOLR-501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12612697#action_12612697
 ] 

Ryan McKinley commented on SOLR-501:


Has anyone looked at this?  Any reason *not* to default the jsp pages to UTF-8?

> /admin/analysis.jsp does not decode input string as UTF-8 sequence.
> ---
>
> Key: SOLR-501
> URL: https://issues.apache.org/jira/browse/SOLR-501
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
> Environment: Tomcat6.0
>Reporter: Hiroaki Kawai
> Attachments: header.jsp.patch
>
>
> In servlet2.5, we should call 
> HttpRequestServlet.setCharacterEncoding("UTF-8") to get a UTF-8 character 
> sequence via request.getParameter() in JSP.

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

Re: Solr 1.3 release date

2008-07-10 Thread Lars Kotthoff

How about getting the user interface I wrote in with the release? I think it'd
make a nice addition as something that's directly visible to the end-user.

Lars

[jira] Commented: (SOLR-565) Component to abstract shards from clients

2008-07-10 Thread Noble Paul നോബിള്‍ नोब्ळ्


[ 
https://issues.apache.org/jira/browse/SOLR-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12612642#action_12612642
 ] 

Yonik Seeley commented on SOLR-565:
---

DistributedSearch was designed such that a custom component could be developed 
that set "shards" dynamically based on it's topology knowledge.  If the main 
point of this patch is to move "shards" from solrconfig.xml to a separate file, 
I'm not sure it's worth it that could perhaps be done with  an XML entity.

If there are separate changes to Distributed Search or ResponseBuilder  that 
will make it easier to write a component to do this, then we should consider 
those changes separately.

> Component to abstract shards from clients
> -
>
> Key: SOLR-565
> URL: https://issues.apache.org/jira/browse/SOLR-565
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Affects Versions: 1.3
>Reporter: patrick o'leary
>Assignee: Otis Gospodnetic
>Priority: Minor
> Fix For: 1.3
>
> Attachments: distributor_component.patch
>
>
> A component that will remove the need for calling clients to provide the 
> shards parameter for
> a distributed search. 
> As systems grow, it's better to manage shards with in solr, rather than 
> managing each client.

-- 
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-561) Solr replication by Solr (for windows also)

The latest patch makes some serious changes to the core Solr classes .
I wish somebody (who knows the core well) to take a look at the
changes and comment on those changes.
The major changes are
* index directory can change
* Core reload
* IndexDeletionPolicy (This patch is Yonik's)

It is important for us to know that our approach is right/acceptable
because we will be rolling this out into production as soon as our QA
team clears the patch.



On Wed, Jul 9, 2008 at 5:01 PM, Noble Paul (JIRA) <[EMAIL PROTECTED]> wrote:
>
> [ 
> https://issues.apache.org/jira/browse/SOLR-561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>  ]
>
> Noble Paul updated SOLR-561:
> 
>
>Attachment: SOLR-561.patch
>
> This patch relies on the IndexDeletionPolicy to identify files to be 
> replicated. It also supposrts replication of conf files.
>
> The configuration is as follows
> on master
> {code:title=solrconfig.xml}
> 
>
>
>commit
>
> schema.xml,stopwords.txt,elevate.xml
>
> 
> {code}
> on slave
> {code:title=solrconfig.xml}
> 
>
> name="masterUrl">http://localhost:port/solr/corename/replication
>00:00:20
> 
> 
> {code}
>
> The Replication strategy is changed as follows
> * CMD_INDEX_VERSION: gets the version of the current _IndexCommit _ to be 
> replicated from the master. if the version is same, no need to replicate. If 
> it is different
> * CMD_FILE_LIST : Get the list of file names for the current _IndexCommit_ . 
> Checks with the local index and identifies modified files by comparing names 
> an sizes.
> * CMD-FILE_CONTENT : For each files to be downloaded, issue this command an 
> download the content to a temp folder. After successful completion copy them 
> to the index folder  and isse a commit
> * If the current index is stale, or not able to synchronize, copy all the 
> files . An index,properties file is written, which has the location of the 
> new index directory
> * _CoreDescriptor_ has a new method to reload core.
> * If conf files are modified they are copied to the conf folder after taking 
> a backup of the old. Then the core is reloaded
>
>
>
>
>
>
>
>
>> Solr replication by Solr (for windows also)
>> ---
>>
>> Key: SOLR-561
>> URL: https://issues.apache.org/jira/browse/SOLR-561
>> Project: Solr
>>  Issue Type: New Feature
>>  Components: replication
>>Affects Versions: 1.3
>> Environment: All
>>Reporter: Noble Paul
>> Attachments: deletion_policy.patch, SOLR-561.patch, SOLR-561.patch, 
>> SOLR-561.patch
>>
>>
>> The current replication strategy in solr involves shell scripts . The 
>> following are the drawbacks with the approach
>> *  It does not work with windows
>> * Replication works as a separate piece not integrated with solr.
>> * Cannot control replication from solr admin/JMX
>> * Each operation requires manual telnet to the host
>> Doing the replication in java has the following advantages
>> * Platform independence
>> * Manual steps can be completely eliminated. Everything can be driven from 
>> solrconfig.xml .
>> ** Adding the url of the master in the slaves should be good enough to 
>> enable replication. Other things like frequency of
>> snapshoot/snappull can also be configured . All other information can be 
>> automatically obtained.
>> * Start/stop can be triggered from solr/admin or JMX
>> * Can get the status/progress while replication is going on. It can also 
>> abort an ongoing replication
>> * No need to have a login into the machine
>> This issue can track the implementation of solr replication in java
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>



-- 
--Noble Paul

[jira] Commented: (SOLR-502) Add search time out support

2008-07-10 Thread Sean Timm (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12612596#action_12612596
 ] 

Sean Timm commented on SOLR-502:


I think that the code is fine as is.  Just the Javadoc comment needs to be 
changed.  The Integer is explicitly cast to a long when it is used.  And as you 
note, 1.6 years is plenty long enough. :-)

> Add search time out support
> ---
>
> Key: SOLR-502
> URL: https://issues.apache.org/jira/browse/SOLR-502
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Reporter: Sean Timm
>Assignee: Yonik Seeley
>Priority: Minor
> Fix For: 1.3
>
> Attachments: SOLR-502.patch, SOLR-502.patch, SOLR-502.patch, 
> SOLR-502.patch, SOLR-502.patch, SOLR-502.patch, solrTimeout.patch, 
> solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch
>
>
> Uses LUCENE-997 to add time out support to Solr.  

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

Re: Solr 1.3 release date

2008-07-10 Thread Noble Paul നോബിള്‍ नोब्ळ्

The contrib patch is already committed. So DIH must be going into
contrib. DIH will be an extra jar in the distro.

If new features/fixes come up later the new jar can be dropped in and
nothing else must break.
If all the the external interfaces/(API & XML) are fine, any other
changes that might come up later should be OK
--Noble


On Thu, Jul 10, 2008 at 10:30 PM, Yonik Seeley <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 10, 2008 at 12:40 PM, Chris Hostetter
> <[EMAIL PROTECTED]> wrote:
>> : We've had enough new features to warrant a new release for quite a
>> : while, so I don't think any new big features should be going in unless
>> : they are ready right now.
>>
>> Looking at the pending issues, the only biggee seems to be SOLR-469,
>> DataImportHandler ... my impression from the list is that it's ready, but
>> that's really a question for Grant.
>
> That's my impression too, but I've not been able to look at it myself.
> It's also going (mostly?) into contrib, right?
>
>> SOLR-303 (Distributed Search) is also still open .. i'm not really
>> clear from the comments what's left for that, but we should either resolve
>> any remaining problems or roll it back to a state where it doesn't
>> adversly affect existing users if it's not ready yet.
>
> I think it's ready to be closed.  There are tons of limitations (i.e.
> much more devel to be done over time), but it's very useful as-is.
>
> -Yonik
>



-- 
--Noble Paul

Re: Solr 1.3 release date

2008-07-10 Thread Yonik Seeley

On Thu, Jul 10, 2008 at 12:40 PM, Chris Hostetter
<[EMAIL PROTECTED]> wrote:
> : We've had enough new features to warrant a new release for quite a
> : while, so I don't think any new big features should be going in unless
> : they are ready right now.
>
> Looking at the pending issues, the only biggee seems to be SOLR-469,
> DataImportHandler ... my impression from the list is that it's ready, but
> that's really a question for Grant.

That's my impression too, but I've not been able to look at it myself.
It's also going (mostly?) into contrib, right?

> SOLR-303 (Distributed Search) is also still open .. i'm not really
> clear from the comments what's left for that, but we should either resolve
> any remaining problems or roll it back to a state where it doesn't
> adversly affect existing users if it's not ready yet.

I think it's ready to be closed.  There are tons of limitations (i.e.
much more devel to be done over time), but it's very useful as-is.

-Yonik

[jira] Commented: (SOLR-624) patch: Don't take snapshot if there are no differences

2008-07-10 Thread Richard "Trey" Hyde (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12612570#action_12612570
 ] 

Richard "Trey" Hyde commented on SOLR-624:
--

My copy of snapcleaner (-N option) from a few weeks ago in 1.3 is also doing 
the snap* thing, you might want to look into that one too.

> patch: Don't take snapshot if there are no differences
> --
>
> Key: SOLR-624
> URL: https://issues.apache.org/jira/browse/SOLR-624
> Project: Solr
>  Issue Type: Improvement
>  Components: replication
>Affects Versions: 1.3
>Reporter: Richard "Trey" Hyde
> Fix For: 1.3
>
> Attachments: solr.check.patch
>
>
> This is similar in concept to a change I made several years ago in Solar.   
> Cronned snapshooters can quickly generate a lot of snaps which will then be 
> unnecessarily distributed to the slaves if there hasn't been any changes in 
> that period.
> Adds a "check" argument to make sure there where changes to the index before 
> taking the snap.

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

[jira] Commented: (SOLR-612) solrj should (optionally?) use POST for queries


[ 
https://issues.apache.org/jira/browse/SOLR-612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12612563#action_12612563
 ] 

Yonik Seeley commented on SOLR-612:
---

Hmmm, I guess with .query() you can't.  I was looking at .request() which takes 
a SolrRequest which has a setMethod() on it.

Perhaps we should add a setter on CommonsHttpSolrServer that can override the 
"GET" of any SolrRequest and change it to "POST"?

> solrj should (optionally?) use POST for queries
> ---
>
> Key: SOLR-612
> URL: https://issues.apache.org/jira/browse/SOLR-612
> Project: Solr
>  Issue Type: Bug
>  Components: clients - java
>Affects Versions: 1.3
> Environment: all
>Reporter: Brian Whitman
> Fix For: 1.3
>
> Attachments: solrj-post.diff
>
>
> Can we make solrj always send post queries (or have it be an init-able 
> option)? 
> Jetty has some "problems" (in quotes because I don't know if it's really a 
> problem) with long queries over GET:
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg09457.html
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200804.mbox/[EMAIL 
> PROTECTED]
> Tiny patch attached that changes it and doesn't cause an exception on long 
> queries in Jetty w/ solrj.

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

Re: Solr 1.3 release date

2008-07-10 Thread Chris Hostetter



: We've had enough new features to warrant a new release for quite a
: while, so I don't think any new big features should be going in unless
: they are ready right now.

Looking at the pending issues, the only biggee seems to be SOLR-469, 
DataImportHandler ... my impression from the list is that it's ready, but 
that's really a question for Grant.

if it takes a few more weeks to get DIH ready, I think holding the release 
is worth while -- there's a lot of interest in getting this into 1.3.

SOLR-303 (Distributed Search) is also still open .. i'm not really 
clear from the comments what's left for that, but we should either resolve 
any remaining problems or roll it back to a state where it doesn't 
adversly affect existing users if it's not ready yet.

Everything else on the list seems like they can easily fall into either 
the "trivial to commit" or "not a big deal to leave out" buckets depending 
on what kind of time people have -- but setting a cut-off date seems fine.



-Hoss

[jira] Commented: (SOLR-612) solrj should (optionally?) use POST for queries

2008-07-10 Thread Brian Whitman (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12612560#action_12612560
 ] 

Brian Whitman commented on SOLR-612:


Well then maybe I just don't understand how to do it right -- how do I tell 
solrj to use post, for this example:

SolrServer s = new CommonsHttpSolrServer("http://localhost:8983/solr";);
SolrQuery q = new SolrQuery();
q.setQuery("type:dog");
QueryResponse qr = s.query(q);

Where in there would I set SolrRequest to use POST?



> solrj should (optionally?) use POST for queries
> ---
>
> Key: SOLR-612
> URL: https://issues.apache.org/jira/browse/SOLR-612
> Project: Solr
>  Issue Type: Bug
>  Components: clients - java
>Affects Versions: 1.3
> Environment: all
>Reporter: Brian Whitman
> Fix For: 1.3
>
> Attachments: solrj-post.diff
>
>
> Can we make solrj always send post queries (or have it be an init-able 
> option)? 
> Jetty has some "problems" (in quotes because I don't know if it's really a 
> problem) with long queries over GET:
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg09457.html
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200804.mbox/[EMAIL 
> PROTECTED]
> Tiny patch attached that changes it and doesn't cause an exception on long 
> queries in Jetty w/ solrj.

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

[jira] Commented: (SOLR-612) solrj should (optionally?) use POST for queries


[ 
https://issues.apache.org/jira/browse/SOLR-612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12612555#action_12612555
 ] 

Yonik Seeley commented on SOLR-612:
---

There are a number of advantages to GET I think... you can see the URLs in the 
servlet container logs, it's explicitly read-only, etc.
People can already use POST by setting the method on SolrRequest object.
Should we really change the default?

> solrj should (optionally?) use POST for queries
> ---
>
> Key: SOLR-612
> URL: https://issues.apache.org/jira/browse/SOLR-612
> Project: Solr
>  Issue Type: Bug
>  Components: clients - java
>Affects Versions: 1.3
> Environment: all
>Reporter: Brian Whitman
> Fix For: 1.3
>
> Attachments: solrj-post.diff
>
>
> Can we make solrj always send post queries (or have it be an init-able 
> option)? 
> Jetty has some "problems" (in quotes because I don't know if it's really a 
> problem) with long queries over GET:
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg09457.html
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200804.mbox/[EMAIL 
> PROTECTED]
> Tiny patch attached that changes it and doesn't cause an exception on long 
> queries in Jetty w/ solrj.

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

Solr 1.3 release date

2008-07-10 Thread Yonik Seeley

I think we need to put a stake in the ground for the 1.3 release...
more issues have been added, and in this mode we will never get there.

Some items *should* hold up a release:
- stability issues
- review of new APIs that will become finalized on release

We've had enough new features to warrant a new release for quite a
while, so I don't think any new big features should be going in unless
they are ready right now.

So how about we make a 1.4 branch in about 2 weeks (the 25th), and
release soon after.

-Yonik

Re: Alternative Spellchecker (spelt)

2008-07-10 Thread Toby Cole

On 10 Jul 2008, at 14:37, Grant Ingersoll wrote:

Have you seen SOLR-572? I'm curious how easy it would be to plug
Spelt into that framework.

I had seen SOLR-572 but not looked into it too hard because our
project required the multi-word correction from XTF.
One thing I had not thought about is the possibility of multiple
dictionaries for different fields, however I reckon this is achievable
as
you can just create a new instance of the spellchecker with a
different data directory.

Otherwise, yes, I am interested in alternatives, but I am not sure
we need separate components for ever spell checker version out
there. I do like the sounds of what you have.

I'll have a look at the SOLR-572 implementation over the weekend and
see if our handlers could fit into that framework somehow.

Cheers, Toby.

-Grant

On Jul 9, 2008, at 6:40 AM, Toby Cole wrote:

Hi,
We've been working on integrating the spelt spellchecker from XTF (http://groups.google.com/group/spelt/
) into solr, and were wondering if anyone else would find it useful.

It is currently implemented as several components:
SpeltComponent - Adds the best suggestion to the solr response as
an array
SpeltFilter & SpeltFilterFactory - Creates a filter which queues
tokens into the spelt index

SpeltHandler - Allows you to query the spellchecker directly
SpeltIndexCreationHandler - Force the creation of the
spellchecking index (typically used if you are not utilizing the
post commit listener, below)
SpeltPostCommitListener - Adds the queued words to the
spellchecking index after each commit.

The approach we have taken is pretty flexible, as it allows you to
decide when to query the spellchecker, and when to create the
index. It has been tested with a corpus of 8 million bibliographic
records, with a total of around 2.3 gig of words queued into it.

Regards, T

PS. Martin Haye
http://markmail.org/message/cqt4qtzzwyceltqu

Toby Cole
Software Engineer

Semantico
Lees House, Floor 1, 21-23 Dyke Road, Brighton BN1 3FE
T: +44 (0)1273 358 238
F: +44 (0)1273 723 232
E: [EMAIL PROTECTED]
W: www.semantico.com

--
Grant Ingersoll
http://www.lucidimagination.com

Lucene Helpful Hints:
http://wiki.apache.org/lucene-java/BasicsOfPerformance
http://wiki.apache.org/lucene-java/LuceneFAQ

Toby Cole
Software Engineer

Semantico
Lees House, Floor 1, 21-23 Dyke Road, Brighton BN1 3FE
T: +44 (0)1273 358 238
F: +44 (0)1273 723 232
E: [EMAIL PROTECTED]
W: www.semantico.com

[jira] Commented: (SOLR-620) Velocity Response Writer


[ 
https://issues.apache.org/jira/browse/SOLR-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12612537#action_12612537
 ] 

Yonik Seeley commented on SOLR-620:
---

bq. however it is probably best for memory usage (or is it?) to continue to use 
the DocList#iterator() so only a single document is loaded at a time

Yes.  That's why I deferred loading documents until response writing so 
things could be streamed one doc at a time.

> Velocity Response Writer
> 
>
> Key: SOLR-620
> URL: https://issues.apache.org/jira/browse/SOLR-620
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Affects Versions: 1.3
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Minor
> Attachments: SOLR-620.jars.zip, SOLR-620.patch, SOLR-620.patch
>
>
> Add a Velocity - http://velocity.apache.org - response writer, making it 
> possible to generate a decent search UI straight from Solr itself.  Designed 
> to work standalone or in conjunction with the JSON response writer (or 
> SolrJS) for Ajaxy things.

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

[jira] Commented: (SOLR-620) Velocity Response Writer


[ 
https://issues.apache.org/jira/browse/SOLR-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12612535#action_12612535
 ] 

Erik Hatcher commented on SOLR-620:
---

Another handy method to get all the documents is 
SolrIndexSearcher#readDocs(Document[] docs, DocList ids) - however it is 
probably best for memory usage (or is it?) to continue to use the 
DocList#iterator() so only a single document is loaded at a time in case there 
are large field values or a lot of documents requested.   Although this point 
will be a bit moot when Velocity layouts are implemented (something I plan to 
do eventually) where the original template is generated into a string buffer 
and then another wrapping template is generated around it.

> Velocity Response Writer
> 
>
> Key: SOLR-620
> URL: https://issues.apache.org/jira/browse/SOLR-620
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Affects Versions: 1.3
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Minor
> Attachments: SOLR-620.jars.zip, SOLR-620.patch, SOLR-620.patch
>
>
> Add a Velocity - http://velocity.apache.org - response writer, making it 
> possible to generate a decent search UI straight from Solr itself.  Designed 
> to work standalone or in conjunction with the JSON response writer (or 
> SolrJS) for Ajaxy things.

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

[jira] Commented: (SOLR-620) Velocity Response Writer


[ 
https://issues.apache.org/jira/browse/SOLR-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12612534#action_12612534
 ] 

Erik Hatcher commented on SOLR-620:
---

Matthias - I removed your patch to keep it clean here.  If you name the patch 
SOLR-620.patch, it will grey out previous versions.  Two comments on your 
patch, be sure to flag your patch as being ok to use within the ASF, and also 
be sure to svn add (locally only of course) the .vm files so they appear in the 
patch too.

> Velocity Response Writer
> 
>
> Key: SOLR-620
> URL: https://issues.apache.org/jira/browse/SOLR-620
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Affects Versions: 1.3
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Minor
> Attachments: SOLR-620.jars.zip, SOLR-620.patch, SOLR-620.patch
>
>
> Add a Velocity - http://velocity.apache.org - response writer, making it 
> possible to generate a decent search UI straight from Solr itself.  Designed 
> to work standalone or in conjunction with the JSON response writer (or 
> SolrJS) for Ajaxy things.

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

[jira] Updated: (SOLR-620) Velocity Response Writer


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

Erik Hatcher updated SOLR-620:
--

Attachment: SOLR-620.patch

Here's an updated patch with a bit more meat to the default.vm, also adding in 
the SolrQueryRequest to the Velocity context.   

I've done it the hard way for now, by navigating the API as rawly as it gets to 
display the documents.   Doing it this way for a bit will inform what kind of 
macros or other context helpers we need to make the view as clean as possible.

> Velocity Response Writer
> 
>
> Key: SOLR-620
> URL: https://issues.apache.org/jira/browse/SOLR-620
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Affects Versions: 1.3
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Minor
> Attachments: SOLR-620.jars.zip, SOLR-620.patch, SOLR-620.patch
>
>
> Add a Velocity - http://velocity.apache.org - response writer, making it 
> possible to generate a decent search UI straight from Solr itself.  Designed 
> to work standalone or in conjunction with the JSON response writer (or 
> SolrJS) for Ajaxy things.

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

[jira] Updated: (SOLR-620) Velocity Response Writer


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

Erik Hatcher updated SOLR-620:
--

Attachment: (was: SOLR-620_20080710.patch)

> Velocity Response Writer
> 
>
> Key: SOLR-620
> URL: https://issues.apache.org/jira/browse/SOLR-620
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Affects Versions: 1.3
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Minor
> Attachments: SOLR-620.jars.zip, SOLR-620.patch, SOLR-620.patch
>
>
> Add a Velocity - http://velocity.apache.org - response writer, making it 
> possible to generate a decent search UI straight from Solr itself.  Designed 
> to work standalone or in conjunction with the JSON response writer (or 
> SolrJS) for Ajaxy things.

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

[jira] Commented: (SOLR-620) Velocity Response Writer