[
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 the r
[
https://issues.apache.org/jira/browse/SOLR-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley updated SOLR-80:
-
Attachment: negative_filters.patch
> negative filter queries
> ---
>
> K
[
https://issues.apache.org/jira/browse/SOLR-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466307
]
Yonik Seeley commented on SOLR-80:
--
attached draft (it doesn't work yet, and there isn't any test code).
> negative fi
On 1/21/07, Mike Klaas <[EMAIL PROTECTED]> wrote:
On 1/20/07, Yonik Seeley (JIRA) <[EMAIL PROTECTED]> wrote:
> > Looking at the negative filters stuff, I realized that andNot() had no
optimized implementation for HashDocSet, so I implemented that and union().
Out of curiosity, what is your cur
[
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
extend
On 1/20/07, Yonik Seeley (JIRA) <[EMAIL PROTECTED]> wrote:
> Looking at the negative filters stuff, I realized that andNot() had no
optimized implementation for HashDocSet, so I implemented that and union().
Out of curiosity, what is your current plan for this? Something along
the lines of s
[
https://issues.apache.org/jira/browse/SOLR-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley resolved SOLR-114.
---
Resolution: Fixed
committed.
> HashDocSet new hash(), andNot(), union()
>
On 1/20/07, Chris Hostetter <[EMAIL PROTECTED]> wrote:
: I'm on board as long as the URL structure is:
: ${path/from/solr/config}?stream.type=raw
actually the URL i was suggesting was...
${parser/path/from/solr/config}${handler/path/from/solr/config}?param=val
...i was trying to avoid ke
[
https://issues.apache.org/jira/browse/SOLR-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466293
]
Yonik Seeley commented on SOLR-116:
---
Facets are slightly different than docfreq's... one is expensive, and one is
ve
[
https://issues.apache.org/jira/browse/SOLR-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466292
]
Erik Hatcher commented on SOLR-116:
---
I had thought of the Map for the field name keyed value as well.
Terms and do
On Sat, 20 Jan 2007, Ryan McKinley wrote:
: Date: Sat, 20 Jan 2007 19:17:16 -0800
: From: Ryan McKinley <[EMAIL PROTECTED]>
: Reply-To: solr-dev@lucene.apache.org
: To: solr-dev@lucene.apache.org
: Subject: Re: Update Plugins (was Re: Handling disparate data sources in
: Solr)
:
: >
: > ...wha
[
https://issues.apache.org/jira/browse/SOLR-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466291
]
Ryan McKinley commented on SOLR-112:
I think that path should be specified explicitly.
I like that
...
will o
...what if we bring that idea back, and let people configure it in the
solrconfig.xml, using path like names...
...but don't make it a *public* interface ... make it package protected,
or maybe even a private static interface of the Dispatch Filter .. either
way, don't instantiate i
(the three of us are online way to much ... for crying out loud it's a
saturday night folks!)
: In my opinion, I don't think we need to worry about it for the
: *default* handler. That is not a very difficult constraint and, there
: is no one out there expecting to be able to post parameters in
On 1/20/07, Yonik Seeley <[EMAIL PROTECTED]> wrote:
> It would be:
> http://${context}/${path}?stream.type=post
Yes!
Feels like a much more natural place to me than as part of the path of the URL.
Just need to hash out meaningful param names/values?
Oh, and I'm more interested in the semantics
On 1/20/07, Ryan McKinley <[EMAIL PROTECTED]> wrote:
> >- put everyone
> > understands how to put something in a URL. if nothing else, think of
> > putting the "parsetype" in the URL as a checksum that the RequestParaser
> > can use to validate it's assumptions -- if it's not there, then it can
>- put everyone
> understands how to put something in a URL. if nothing else, think of
> putting the "parsetype" in the URL as a checksum that the RequestParaser
> can use to validate it's assumptions -- if it's not there, then it can do
> all of the intellegent things you think it should do, bu
[
https://issues.apache.org/jira/browse/SOLR-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466290
]
Hoss Man commented on SOLR-112:
---
random idea i had that we might consider, not sure yet if i like it yet but i
wanted to
> consider the example you've got on your test.html page: "POST - with query
> string" ... that doesn't obey the typical semantics of a POST with a query
> string ... if you used the methods on HttpServletRequest to get the params
> it would give you all the params it found both in the query stri
On 1/20/07, Chris Hostetter <[EMAIL PROTECTED]> wrote:
but the HTTP Client libraries in vaious languages don't allways make it
easy to set Content-type -- and even if they do that doesn't mean the
person using that library knows how to use it properly -
I think we have to go with common usages.
On 1/20/07, Chris Hostetter <[EMAIL PROTECTED]> wrote:
Ryan: this patch truely does kick ass ... we can probably simplify a lot
of the Legacy stuff by leveraging your new StandardRequestBuilder -- but
that can be done later.
Much is already done by the looks of it.
i'm stil really not liking
: To be clear, (with the current implementation in SOLR-104) you would
: have to put this in your solrconfig.xml
:
:
:
: Notice the preceding '/'. I think this is a strong indication that
: someone *wants* /select to behave distinctly.
crap ... i totally misread that ... so if people have a req
: I just posted a new patch on SOLR-104. I think it addresses most of
: the issues we have discussed. (Its a little difficult to know as it
: has been somewhat circular) I was going to reply to your points one
: by one, but i think that would just make the discussion more confusing
: then it a
easy thing to deal with just by scoping the URLs .. put something,
ANYTHING, in front of these urls, that isn't "select" or "update" and
I'll let you and Yonik decide this one. I'm fine either way, but I
really don't see a problem letting people easily override URLs. I
actually think it is a
: > that scares me ... not only does it rely on the client code sending the
: > correct content-type
:
: Not really... that would perhaps be the default, but the parser (or a
: handler) can make intelligent decisions about that.
:
: If you put the parser in the URL, then there's *that* to be messe
: > A user should be confident that they can pick anyname they possily want
: > for their plugin, and it won't collide with any future addition we might
: > add to Solr.
:
: But that doesn't seem possible unless we make user plugins
: second-class citizens by scoping them differently. In the even
[
https://issues.apache.org/jira/browse/SOLR-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466277
]
Ryan McKinley commented on SOLR-104:
I just thought of something that will make Hoss' blod curl! I KNOW it
is a b
I just posted a new patch on SOLR-104. I think it addresses most of
the issues we have discussed. (Its a little difficult to know as it
has been somewhat circular) I was going to reply to your points one
by one, but i think that would just make the discussion more confusing
then it already is!
[
https://issues.apache.org/jira/browse/SOLR-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466273
]
Ryan McKinley commented on SOLR-104:
I just updated DispatchFilter.path to implement most of our discussion on
sol
[
https://issues.apache.org/jira/browse/SOLR-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-104:
---
Attachment: commons-io-1.2.jar
> Update Plugins
> --
>
> Key: SOLR-104
>
[
https://issues.apache.org/jira/browse/SOLR-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-104:
---
Attachment: DispatchFilter.patch
> Update Plugins
> --
>
> Key: SOLR-104
>
[
https://issues.apache.org/jira/browse/SOLR-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-104:
---
Attachment: commons-fileupload-20070107.jar
> Update Plugins
> --
>
> Key:
>
> 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 Servlet -- i honestly have no opinion
> about that either way.
I thought a filter required you to open up the WAR file and c
[
https://issues.apache.org/jira/browse/SOLR-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466248
]
Yonik Seeley commented on SOLR-116:
---
If you want to commit early and still mess around with the parameters and
respo
[
https://issues.apache.org/jira/browse/SOLR-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466247
]
Yonik Seeley commented on SOLR-116:
---
Looks good, I like the fieldnames as the keys. The only change I might make is
Chris Hostetter wrote:
: 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 Servlet
[
https://issues.apache.org/jira/browse/SOLR-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466226
]
Erik Hatcher commented on SOLR-116:
---
The initial example was from an older example index. From trunk, the response
[
https://issues.apache.org/jira/browse/SOLR-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik Hatcher updated SOLR-116:
--
Attachment: structure_handler.patch
> StructureRequestHandler - allowing client to discover all fields in
StructureRequestHandler - allowing client to discover all fields in the index
-
Key: SOLR-116
URL: https://issues.apache.org/jira/browse/SOLR-116
Project: Solr
Issue
39 matches
Mail list logo
