At 5:12 PM -0400 7/1/08, Grant Ingersoll wrote:
You make a good point about the countless hours debugging. On the flip side,
one could ask the question as to whether the Solr schema is stable enough that
we should publish an XML Schema for it, thus helping alleviate some of the
pain.
That's a
Beware... I just looked at CharArraySet at -rHEAD and it *modifies the input
token* if ignoreCase is set:
/** Add this char[] directly to the set.
* If ignoreCase is true for this Set, the text array will be directly
modified.
* The user should never modify this text array after calling
penalty from the need to re-multiplex everything, and some of the
limitations of j.u.l. remain in effect.
So count me as another attentive listener if anyone has some experience or at
least gossip pro or con either sl4j or the jul-log4j-bridge.
Thanks,
J.J. Larrea
At 6:13 AM -0800 11/14/07, Henrib
[
https://issues.apache.org/jira/browse/SOLR-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535321
]
J.J. Larrea commented on SOLR-351:
--
My apologies for these last-minute peanut-gallery comments, and especially
[
https://issues.apache.org/jira/browse/SOLR-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532570
]
J.J. Larrea commented on SOLR-42:
-
Here is the workaround I am using, along with a long comment explaining why
[
https://issues.apache.org/jira/browse/SOLR-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532570
]
skeptikos edited comment on SOLR-42 at 10/4/07 9:45 PM:
--
Here is the workaround I am using,
[
https://issues.apache.org/jira/browse/SOLR-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532570
]
skeptikos edited comment on SOLR-42 at 10/4/07 10:03 PM:
---
Here is the workaround I am using,
[
https://issues.apache.org/jira/browse/SOLR-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525304
]
J.J. Larrea commented on SOLR-195:
--
Until such time as someone implements one of the approaches for extractTerms
[
https://issues.apache.org/jira/browse/SOLR-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515809
]
J.J. Larrea commented on SOLR-320:
--
This was biting me too... thanks for filing the detailed report + testcase,
Stu
[
https://issues.apache.org/jira/browse/SOLR-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514541
]
J.J. Larrea commented on SOLR-314:
--
I agree that a stored-field pre-processor would be quite useful, but I'm
Thanks, Yonik - I think that was a record for me (you committed a fix 40
minutes from when I reported the issue)!
- J.J.
At 12:40 AM -0400 6/21/07, Yonik Seeley wrote:
Thanks J.J., I just committed the fix.
sortMissing* was added later and was simply missed for TextField.
-Yonik
I very much support a plugin architecture for ResponseHandlers.
One aspect could be a Responselet which adds something to the response, as
detailed in Ryan's example below. Quite valuable in itself.
But another aspect could be a Querylet which adds something to the query
before execution.
[
https://issues.apache.org/jira/browse/SOLR-248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498817
]
J.J. Larrea commented on SOLR-248:
--
While I fully agree that faceting does raise some odd issues stemming from
[
https://issues.apache.org/jira/browse/SOLR-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12496046
]
J.J. Larrea commented on SOLR-221:
--
Clearly Solr is going to end up with more than 2 algorithms for computing
facets
[
https://issues.apache.org/jira/browse/SOLR-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493957
]
J.J. Larrea commented on SOLR-228:
--
The SolrParams API seems to be set-complete, the only thing missing is the
non
I've got those in in my local patched copy of Solr, so +0.5 on one less
triviality to maintain, and +0.5 on set closure (but don't forget the
non-default getFieldFloat as well). -J.J.
At 11:55 PM -0400 5/4/07, Ryan McKinley wrote:
SolrParams seems to have most options for how to get whom from
[
https://issues.apache.org/jira/browse/SOLR-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493466
]
J.J. Larrea commented on SOLR-212:
--
One issue which comes up both DirectSolrConnection.java and the
http
[
https://issues.apache.org/jira/browse/SOLR-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482686
]
J.J. Larrea commented on SOLR-183:
--
Thanks for clarifying the semantics and the implementation, Ryan.
It's fine
[
https://issues.apache.org/jira/browse/SOLR-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482455
]
J.J. Larrea commented on SOLR-183:
--
I totally agree with Ryan that the question I raised about the value
[
https://issues.apache.org/jira/browse/SOLR-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
J.J. Larrea updated SOLR-183:
-
Attachment: SOLR-183-required-param.patch
add getRequiredParameter() to SolrParams
[
https://issues.apache.org/jira/browse/SOLR-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478895
]
J.J. Larrea commented on SOLR-183:
--
Er, sorry to be contrary, but to me it seems a bit excessive to go through so
[
https://issues.apache.org/jira/browse/SOLR-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478930
]
J.J. Larrea commented on SOLR-183:
--
Modest proposal: If one is going to come up with a programmer-facing mechanism
[
https://issues.apache.org/jira/browse/SOLR-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
J.J. Larrea updated SOLR-183:
-
Attachment: RequiredSolrParams.java
add getRequiredParameter() to SolrParams
[
https://issues.apache.org/jira/browse/SOLR-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478980
]
J.J. Larrea commented on SOLR-183:
--
By the way, I think your logic to catch type conversion errors and return 400
[
https://issues.apache.org/jira/browse/SOLR-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12479175
]
J.J. Larrea commented on SOLR-183:
--
I was unfortunately not very clear, and confounded 2 things, an enhanced
At 11:30 PM -0800 2/21/07, Ryan McKinley wrote:
The question is do we want to add *another* parameter to say don't
parse the ; sort even if i don't specify the sort parameter?
Yes, testing the existence/non-existence of a param is not great - but
I don't think adding another field is worth it for
At 9:42 PM -0800 2/21/07, Chris Hostetter wrote:
yeah ... the semantics discussed previously for backwards compatibility
were...
1) if sort param, use it and do no special ; parsing
2) if no sort param, check for ; and extract sort
FWIW, in an in-progress refactoring of StandardRequestHandler
[
https://issues.apache.org/jira/browse/SOLR-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469603
]
J.J. Larrea commented on SOLR-133:
--
It would be useful if there first were some consensus as to what the goals
At 11:17 AM -0800 1/23/07, Chris Hostetter wrote:
my point was just that if you arne't very familiar with teh syntax and
you say: q=* you might assuming you'll get all docs -- and unless your
defaultSearchField is something weird, you will get a lot of docs, but not
neccessarily all. if someone
At 8:24 PM -0800 1/22/07, Chris Hostetter wrote:
: So now that we have negative queries, we don't really need any
: additional/extra code for facet.missing. It could simply be
: facet.query=-myfield:*, and that way it could be obtained without
: getting facet.field results if desired.
[
https://issues.apache.org/jira/browse/SOLR-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466317
]
J.J. Larrea commented on SOLR-112:
--
Regarding SOLR-112.patch, +1 on on the NamedList changes included from SOLR-107
At 1:20 AM -0800 1/21/07, Chris Hostetter wrote:
: We need code to do that anyway since getParameterMap() doesn't support
: getting params from the URL if it's a POST (I believe I tried this in
: the past and it didn't work).
Uh ... i'm pretty sure you are mistaken ... yep, i've just checked and
[
https://issues.apache.org/jira/browse/SOLR-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466304
]
J.J. Larrea commented on SOLR-112:
--
I'm sure you won't like your extemperaneous suggestion (foo/baz implicitly
[
https://issues.apache.org/jira/browse/SOLR-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466308
]
J.J. Larrea commented on SOLR-112:
--
Re foo vs. /foo:
I think of the SolrServlet as being just one way to invoke
At 11:48 PM -0800 1/16/07, Chris Hostetter wrote:
yeah ... once we have a RequestHandler doing that work, and populating a
SolrQueryResponse with it's result info, it
would probably be pretty trivial to make an extremely bare-bones
LegacyUpdateOutputWRiter that only expected that simple mount of
I'm in frantic deadline mode so I'm just going to throw in some (hopefully)
short comments...
At 11:02 PM -0800 1/15/07, Ryan McKinley wrote:
the one thing that still seems missing is those micro-plugins i was
[SNIP]
interface SolrRequestParser {
SolrRequest process( HttpServletRequest
[
https://issues.apache.org/jira/browse/SOLR-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464648
]
J.J. Larrea commented on SOLR-20:
-
Regarding Hoss' point #3, perhaps it's time to reorganize into something like
/solr
[
https://issues.apache.org/jira/browse/SOLR-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464653
]
J.J. Larrea commented on SOLR-104:
--
I think this is a fantastic effort, so please take my comments and suggestions
[
https://issues.apache.org/jira/browse/SOLR-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464654
]
J.J. Larrea commented on SOLR-104:
--
6. I may be going a little crazy with this soft-configuration concept
[
https://issues.apache.org/jira/browse/SOLR-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464658
]
J.J. Larrea commented on SOLR-106:
--
+1 on direction, and based on a quick scan of the patch.
It could be sort=asc
At 6:43 AM -0500 1/11/07, Erik Hatcher wrote:
If all fields are stored, the implementation could simply pull them all into
memory on the Solr side and add the document as if it had been sent entirely
by the client. But, what happens when for un-stored fields?
I'll observe that Luke has a
41 matches
Mail list logo
