Support 'random' sort order
---
Key: SOLR-264
URL: https://issues.apache.org/jira/browse/SOLR-264
Project: Solr
Issue Type: New Feature
Reporter: Ryan McKinley
Priority: Minor
Support
[
https://issues.apache.org/jira/browse/SOLR-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-264:
---
Attachment: SOLR-264-RandomSortOrder.patch
Implements a 'ScoreDocComparator' that returns a random
[
https://issues.apache.org/jira/browse/SOLR-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley resolved SOLR-69.
---
Resolution: Fixed
PATCH:MoreLikeThis support
--
Key:
[
https://issues.apache.org/jira/browse/SOLR-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-103:
---
Attachment: SOLR-103-SQLUpdateRequestHandler.patch
updated to work with trunk...
(i haven't used this
See http://lucene.zones.apache.org:8080/hudson/job/Solr-Nightly/115/changes
--
started
Checking out http://svn.apache.org/repos/asf/lucene/solr/trunk
AUNOTICE.txt
AULICENSE.txt
A site
AUsite/index.pdf
AU
It's a relief to know this is not out of the project scope.
Do you have any recommendation to ease keeping the patch 'up to date' with
the trunk?
What else can/should I do to help the review?
Yonik Seeley wrote:
On 6/15/07, Henrib [EMAIL PROTECTED] wrote:
The idea of the multiple
[
https://issues.apache.org/jira/browse/SOLR-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505846
]
Will Johnson commented on SOLR-239:
---
after looking at all the dependencies for IndexSchema and with the addition of
See http://lucene.zones.apache.org:8080/hudson/job/Solr-Nightly/116/changes
--
[...truncated 862 lines...]
A client/ruby/solr-ruby/test/unit
A client/ruby/solr-ruby/test/unit/document_test.rb
A
[
https://issues.apache.org/jira/browse/SOLR-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505880
]
Ryan McKinley commented on SOLR-264:
Rather than mess with query parsing to hack in support for a random key
[
https://issues.apache.org/jira/browse/SOLR-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-264:
---
Attachment: SOLR-264-RandomSortOrder.patch
Random sorting implemented as a FieldType.
to enable
[
https://issues.apache.org/jira/browse/SOLR-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505927
]
Yonik Seeley commented on SOLR-265:
---
Doesn't this have thread-saftey and unsolvable consistency issues?
It doesn't
[
https://issues.apache.org/jira/browse/SOLR-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505938
]
Will Johnson commented on SOLR-265:
---
After doing some more thinking about the issue after I submitted the
patch I
[
https://issues.apache.org/jira/browse/SOLR-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505950
]
Ryan McKinley commented on SOLR-265:
I haven't looked at the patch, but have a couple questions:
* What is the
: Do you have any recommendation to ease keeping the patch 'up to date' with
: the trunk?
One trick i've seen people talk about but haven't had much experience with
myself is that if a patch made by svn diff doesn't apply cleanly with
the truck because of subsequent changes, grep the patch for
Lucene-Java currently has a 2.2 release candidate available, and people
are already talking about having a release post-mortem discussion to
discuss what worked well/badly in the rleease process, and make sure the
process documentation is up to date.
The reminded me that i wanted ot suggest the
I'm not sure how this would be done and I don't want to take away
from the great work done on the Wiki, but some type of versioning is
needed so that we know what version of the wiki corresponds to what
release (now that we have a few releases). I know from legal (see
the legal-discuss
I haven't looked at the patch, but have a couple questions:
* What is the motivation/use case for editing the schema at runtime? (I'm not
suggesting there aren't good ones, just curious)
to add new fields on the fly without having any search downtime
* Would changes be saved?
the patch as is
[
https://issues.apache.org/jira/browse/SOLR-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-264:
---
Attachment: SOLR-264-RandomSortOrder.patch
using:
rand.nextBoolean() ? -1 : 1;
the fancy pants
Let the LukeRequestHandler return parsed schema information
---
Key: SOLR-266
URL: https://issues.apache.org/jira/browse/SOLR-266
Project: Solr
Issue Type: Improvement
: * What is the motivation/use case for editing the schema at runtime?
: (I'm not suggesting there aren't good ones, just curious)
:
: to add new fields on the fly without having any search downtime
i haven't read anything in the jira issue this refrences, but in instances
where reliability and
Congratulations with SOLR-1.2.0!
The only problem is changed protocols, old client application does not
understand new XML responses from server. It recalls some very old
discussions related to JSON-based Java(!) client for Java(!) server (sure,
RMI is the purest... Forgotten!). Same is true for
: The only problem is changed protocols, old client application does not
: understand new XML responses from server. It recalls some very old
Can you elaborate on what XML responses have changed for you? To the
best of my knowledge any solrconfig.xml that worked with Solr 1.1 will
continue to
[
https://issues.apache.org/jira/browse/SOLR-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-266:
---
Attachment: SOLR-266-LukeSchemaInfo.patch
Let the LukeRequestHandler return parsed schema information
Ya, Hudson has been having the occasional problem with SVN
checkouts. I'm monitoring the Hudson lists for a fix or workaround.
Cheers,
Nige
On Jun 6, 2007, at 9:56 AM, Yonik Seeley wrote:
On 6/6/07, Ryan McKinley [EMAIL PROTECTED] wrote:
I assume this is not something we worry about? It
On Jun 16, 2007, at 11:01 AM, Chris Hostetter wrote:
: Is there any downside to switching to hudson?
someone has to learn how to configure it (my main impression: it's got
a lot more bells and whistles then a shell script cron job, but a
shell
script cronjob is pretty easy to read and
25 matches
Mail list logo
