On 1/20/07, Chris Hostetter <[EMAIL PROTECTED]> wrote:
: I have imagined the single default parser handles *all* the cases you
: just mentioned.
A ... a lot of confusing things make more sense now. .. but
some things are more confusing: If there is only one parser, and it
decides wha
On 1/20/07, Chris Hostetter <[EMAIL PROTECTED]> wrote:
the thing about Solr, is there really aren't a lot of "defaults" in the
sense you mean ... there is just an example -- people might copy the
example, but if they don't have something in their solrconfig, most things
just aren't there
I
i would relaly feel a lot happier with something like these that you
mentioned...
If it will make you happier, then I think its a good idea! (even if i
don't see it as a Problem)
: /solr/dispatch/update/xml
: /solr/cmd/update/xml
: /solr/handle/update/xml
: /solr/do/update/xml
http
: I have imagined the single default parser handles *all* the cases you
: just mentioned.
A ... a lot of confusing things make more sense now. .. but
some things are more confusing: If there is only one parser, and it
decides what to do based entirely on param names and HTTP headers,
:
: This would drop the ':' from my proposed URL and change the scheme to look
like:
: /parser/path/the/parser/knows/how/to/extract/?params
i was totally okay with the ":" syntax (although we should double check if
":" is actaully a legal unescaped URL character) .. but i'm confused by
this new
: > then all is fine and dandy ... but what happens if someone tries to
: > configure a plugin with the name "admin" ... now all of the existing admin
: that is exactly what you would expect to happen if you map a handler
: to /admin. The person configuring solrconfig.xml is saying "Hey, use
:
On 1/20/07, Ryan McKinley <[EMAIL PROTECTED]> wrote:
>
> what!? .. really? ... you don't think the ones i mentioned before are
> things we should support out of the box?
>
> - no stream parser (needed for simple GETs)
> - single stream from raw post body (needed for current updates
> -
: > This would give people a relativly easy way to implement 'restful'
: > URLs if they need to. (but they would have to edit web.xml)
:
: A handler could alternately get the rest of the path (absent params), right?
only if the RequestParser adds it to the SolrRequest as a SolrParam.
: > Unit t
what!? .. really? ... you don't think the ones i mentioned before are
things we should support out of the box?
- no stream parser (needed for simple GETs)
- single stream from raw post body (needed for current updates
- multiple streams from multipart mime in post body (needed for SOLR
: The RequestParser is not be part of the core API - It would be a
: helper function for Servlets and Filters that call the core API. It
: could be configured in web.xml rather then solrconfig.xml. A
: RequestDispatcher (Servlet or Filter) would be configured with a
: single RequestParser.
:
: T
On 1/19/07, Chris Hostetter <[EMAIL PROTECTED]> wrote:
: First Ryan, thank you for your patience on this *very* long hash
I could not agree more ... as i was leaving work this afternoon, it
occured to me "I really hope Ryan realizes i like all of his ideas, i'm
just wondering if they can be bet
: First Ryan, thank you for your patience on this *very* long hash
I could not agree more ... as i was leaving work this afternoon, it
occured to me "I really hope Ryan realizes i like all of his ideas, i'm
just wondering if they can be better" -- most people I work with don't
have the stamina to
replace BooleanQuery.getClauses() with clauses()
Key: SOLR-115
URL: https://issues.apache.org/jira/browse/SOLR-115
Project: Solr
Issue Type: Improvement
Reporter: Yonik Seeley
On 1/19/07, Erik Hatcher <[EMAIL PROTECTED]> wrote:
I don't _think_ this is currently possible, but it might be a slick
thing to add...
I'm pretty sure not... according to http://issues.apache.org/jira/browse/SOLR-21
where *_sort could be defined as:
("lowercased" is just
First Ryan, thank you for your patience on this *very* long hash
session. Most wouldn't last that long unless it were a flame war ;-)
And thanks to Hoss, who seems to have the highest read+response
bandwidth of anyone I've ever seen (I'll admit I've only been
selectively reading this thread, with
On 1/19/07, Yonik Seeley (JIRA) <[EMAIL PROTECTED]> wrote:
[
https://issues.apache.org/jira/browse/SOLR-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466176
]
Yonik Seeley commented on SOLR-114:
---
tested on an AMD opt
(Note: this is different then what i have suggested before. Treat it
as brainstorming on how to take what i have suggested and mesh it with
your concerns)
What if:
The RequestParser is not be part of the core API - It would be a
helper function for Servlets and Filters that call the core API.
I don't _think_ this is currently possible, but it might be a slick
thing to add...
where *_sort could be defined as:
("lowercased" is just something I made up for this e-mail, but could
be a type that simply emits a single token, lowercased from the
original)
The pat
On 1/19/07, Ryan McKinley <[EMAIL PROTECTED]> wrote:
All that said, this could just as cleanly map everything to:
/solr/dispatch/update/xml
/solr/cmd/update/xml
/solr/handle/update/xml
/solr/do/update/xml
thoughts?
That was my original assumption (because I was thinking of using
servle
then all is fine and dandy ... but what happens if someone tries to
configure a plugin with the name "admin" ... now all of the existing admin
pages break.
that is exactly what you would expect to happen if you map a handler
to /admin. The person configuring solrconfig.xml is saying "Hey, use
: > On 1/19/07, Chris Hostetter <[EMAIL PROTECTED]> wrote:
: > > whoa ... hold on a minute, even if we use a ServletFilter do do all of the
: > > dispatching instead of a Servlet we still need a base path right?
: > I thought that's what the filter gave you... the ability to filter any
: > URL to
On 1/19/07, Yonik Seeley <[EMAIL PROTECTED]> wrote:
On 1/19/07, Chris Hostetter <[EMAIL PROTECTED]> wrote:
> whoa ... hold on a minute, even if we use a ServletFilter do do all of the
> dispatching instead of a Servlet we still need a base path right?
I thought that's what the filter gave you...
On 1/19/07, Chris Hostetter <[EMAIL PROTECTED]> wrote:
whoa ... hold on a minute, even if we use a ServletFilter do do all of the
dispatching instead of a Servlet we still need a base path right?
I thought that's what the filter gave you... the ability to filter any
URL to the /solr webapp, and
[
https://issues.apache.org/jira/browse/SOLR-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466176
]
Yonik Seeley commented on SOLR-114:
---
tested on an AMD opteron, 64 bit mode, Java5 -server -Xbatch and exists() was
8
: 1) I think it should be a ServletFilter applied to all requests that
: will only process requests with a registered handler.
I'm not sure what "it" is in the above sentence ... i believe from the
context of the rest of hte message you are you refering to
using a ServletFilter instead of a Servl
[
https://issues.apache.org/jira/browse/SOLR-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley updated SOLR-114:
--
Attachment: test.patch
> HashDocSet new hash(), andNot(), union()
> -
[
https://issues.apache.org/jira/browse/SOLR-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466166
]
Yonik Seeley commented on SOLR-114:
---
The performance tests are commented out in the TestDocSet test... I had other
[
https://issues.apache.org/jira/browse/SOLR-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466160
]
Hoss Man commented on SOLR-114:
---
quick questions...
1) what test did you run to get those numbers? ... even if we don't
[
https://issues.apache.org/jira/browse/SOLR-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466154
]
Yonik Seeley commented on SOLR-114:
---
Performance results:
- HashDocSet.exists() is 13% faster
- HashDocSet.inters
[
https://issues.apache.org/jira/browse/SOLR-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley updated SOLR-114:
--
Attachment: hashdocset.patch
> HashDocSet new hash(), andNot(), union()
> ---
HashDocSet new hash(), andNot(), union()
Key: SOLR-114
URL: https://issues.apache.org/jira/browse/SOLR-114
Project: Solr
Issue Type: Improvement
Components: search
Reporter: Yoni
On 1/19/07, Walter Underwood <[EMAIL PROTECTED]> wrote:
Ultraseek does exactly that and is a single multi-threaded process.
A single process is much easier for the admin. A multi-process solution
is more complicated to start up, monitor, shut down, and upgrade.
There is decent demand for a spid
Ok, now i think I get what you are suggesting. The differences are that:
1) I think it should be a ServletFilter applied to all requests that
will only process requests with a registered handler.
2) I think the RequestParser should take care off parsing
ContentStreams *and* SolrParams - not just
: I'm running multiple instances of Solr, which all using the same war
: file to load from. To log to separate files I implemented the following
: kludge.
Ben: I'm glad you managed to get your situation working, but did you try
the instructions on the TomCat documentation page about configuring
On 1/19/07 10:33 AM, "Chris Hostetter" <[EMAIL PROTECTED]> wrote:
> [...] but if your interest is in
> having an "enterprise search solution" that people can deploy on a box
> and haveit start working for them, then there is no reason for all of that
> code to run in a single JVM using a single co
: > What I am really talking about, is this: There is a growing market for
: > simple search solutions that can work out of the box, and that can still
: > be customized. Something that:
: > - organizations can use on their network, out of the box
: > I am not looking to change Solr in that direct
Some example + post.sh in docs in client/solrb
--
Key: SOLR-113
URL: https://issues.apache.org/jira/browse/SOLR-113
Project: Solr
Issue Type: Wish
Components: clients - ruby - flare
37 matches
Mail list logo
