[
https://issues.apache.org/jira/browse/SOLR-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506054
]
Yonik Seeley commented on SOLR-264:
---
> the fancy pants >>> returns a distribution 0,1 -- to get a reasonable random
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 under
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
[
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
: 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
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 R
: >* 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
Let the LukeRequestHandler return parsed schema information
---
Key: SOLR-266
URL: https://issues.apache.org/jira/browse/SOLR-266
Project: Solr
Issue Type: Improvement
Repor
[
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 >>> r
>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
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 arc
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 s
: 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
[
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 moti
[
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 agr
[
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 se
[
https://issues.apache.org/jira/browse/SOLR-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Johnson updated SOLR-265:
--
Attachment: IndexSchemaReload.patch
updates to:
* solconfig.xml to register handler
* IndexSchema to add
[
https://issues.apache.org/jira/browse/SOLR-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505901
]
Yonik Seeley commented on SOLR-264:
---
nextFloat() generates a random int and then does a floating point divide (one
o
[
https://issues.apache.org/jira/browse/SOLR-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Keller updated SOLR-236:
-
Attachment: (was: SOLR-236-FieldCollapsing.patch)
> Field collapsing
>
>
>
[
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 random
[
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-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505866
]
Koji Sekiguchi commented on SOLR-103:
-
It worked well for me. Thank you.
> SQL Upload Plugin
> -
>
[
https://issues.apache.org/jira/browse/SOLR-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505860
]
Yonik Seeley commented on SOLR-264:
---
Rather than mess with query parsing to hack in support for a "random" key word,
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 client/ruby/solr-ruby/test/unit/standard
Make IndexSchema updateable in live system
--
Key: SOLR-265
URL: https://issues.apache.org/jira/browse/SOLR-265
Project: Solr
Issue Type: Improvement
Components: update
Affects Versions:
[
https://issues.apache.org/jira/browse/SOLR-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated SOLR-215:
---
Attachment: solr-215.patch
update to current trunk; patch generated from a Solaris Express 10 box.
> M
[
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
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 core
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
AUsite/features.h
[
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
[
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: SOL
[
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 numb
32 matches
Mail list logo