[
https://issues.apache.org/jira/browse/SOLR-415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koji Sekiguchi updated SOLR-415:
Attachment: SOLR-415.patch
> LoggingFilter for debug
> ---
>
> Ke
LoggingFilter for debug
---
Key: SOLR-415
URL: https://issues.apache.org/jira/browse/SOLR-415
Project: Solr
Issue Type: Improvement
Reporter: Koji Sekiguchi
Priority: Trivial
logging version of a
: I think it does make sense to keep them together.
: offset and length only make sense if an ordering is specified.
true.
: If we change the name, we should also move it to a top-level class
: (from a static inner).
: Any suggestions?
good point .. promoting it to first order is probably more
since 99% of hte use cases are pulling sort, rows, and start from some
SOlrParams, that use case should probably be refactored into a utility
method as well.
While we are at it, we should limit consolidate the null sort checking.
See: http://www.nabble.com/Sorting-problem-tf4762114.html#a
: I don't follow i) -- my complaint about the multiple init() interfaces is that
: it just feels wierd to have:
:
: void init( Map args )
: *and*
: void init( ResourceFinder finder )
:
: when what you really want is:
:
: void init( ResourceFinder finder, Map args )
I disagree. even if we d
[
https://issues.apache.org/jira/browse/SOLR-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543924
]
Hoss Man commented on SOLR-416:
---
FWIW: 'grep -r "toUpper\|toLower" java webapp' shows 32 places where toUpper or
toLower
I recently fixed this in the trunk.
-Yonik
On Nov 20, 2007 10:31 AM, Rishabh Joshi <[EMAIL PROTECTED]> wrote:
> Hi,
>
> We are using Solr 1.2 for our project and have come across the following
> exception and error:
>
> Exception:
> SEVERE: java.lang.OutOfMemoryError: Java heap space
> at org.
need to audit all methods that might be using default Locale
Key: SOLR-416
URL: https://issues.apache.org/jira/browse/SOLR-416
Project: Solr
Issue Type: Bug
Reporter: H
Hi,
We are using Solr 1.2 for our project and have come across the following
exception and error:
Exception:
SEVERE: java.lang.OutOfMemoryError: Java heap space
at org.apache.lucene.util.PriorityQueue.initialize (PriorityQueue.java
:36)
Steps to reproduce:
1. Restart your Web Server.
2. Ente
: While we are at it, we should limit consolidate the null sort checking. See:
: http://www.nabble.com/Sorting-problem-tf4762114.html#a13627492
:
: Currently for "score desc", the parsing utility returns a null SortSpec, then
: has to create a new one to attach rows/offset
+1 ... there's no rea
[
https://issues.apache.org/jira/browse/SOLR-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley updated SOLR-303:
--
Description:
Searching over multiple shards and aggregating results.
Motivated by http://wiki.apache.org/
[
https://issues.apache.org/jira/browse/SOLR-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543932
]
Yonik Seeley commented on SOLR-416:
---
I personally hate case insensitivity for parameters if not explicitly
docum
[
https://issues.apache.org/jira/browse/SOLR-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543931
]
Hoss Man commented on SOLR-303:
---
Note: there has been discussion recently about the terminology distinction
between "fed
: It's cool to know about the jul-log4j-bridge and I like the way with a
: single method call one can effectively short-circuit j.u.l. by stealing
: its output, but on very quick read it appears there is a potentially
: non-trivial performance penalty from the need to re-multiplex
: everything
[
https://issues.apache.org/jira/browse/SOLR-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543970
]
Hoss Man commented on SOLR-409:
---
i'm not sure how to interpret "Yes #1, not #2" ... are you saying my
understanding abou
...the only thing slightly non-standard about calling these methods
"setters" is that they aren't expected to jsut be "POJO" style setters ...
the expectation is that the class will do some work when they are called
-- hence my "tell" (or maybe "notify" or "inform" is a better verb)
suggest
[
https://issues.apache.org/jira/browse/SOLR-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544016
]
Ryan McKinley commented on SOLR-409:
I agree with everything you say above.
Lets take the approach in #1 and avoid
I started implementing this suggestion and am running into one hitch.
The cleanest solution is to have a single place manage Aware/Inform.
The cleanest place for this is in ResourceLoader (refactored Config
superclass)
public Object newInstance(String cname, String... subpackages) {
...
[
https://issues.apache.org/jira/browse/SOLR-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-414:
---
Attachment: SOLR-414-Initialization.patch
Updated patch to reflect ideas discussed in:
http://www.nabbl
Move SortSpec to top level class and cleanup
Key: SOLR-417
URL: https://issues.apache.org/jira/browse/SOLR-417
Project: Solr
Issue Type: Improvement
Components: search
Report
[
https://issues.apache.org/jira/browse/SOLR-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-417:
---
Attachment: SOLR-417-SortSpec.patch
Moves SortSpec to its own class and cleans up lots of null checking
[
https://issues.apache.org/jira/browse/SOLR-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544118
]
ryantxu edited comment on SOLR-417 at 11/20/07 3:44 PM:
--
Moves SortSpec to its own class a
Looks good for me, thanks.
Ryan McKinley (JIRA) wrote:
[ https://issues.apache.org/jira/browse/SOLR-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544118 ]
ryantxu edited comment on SOLR-417 at 11/20/07 3:44 PM:
-
23 matches
Mail list logo
