On May 2, 2007, at 3:21 PM, Mike Klaas wrote:
On 5/2/07, Brian Whitman <[EMAIL PROTECTED]> wrote:
Would love to set a custom fragmenter in Solr for highlighting. But I
don't see a way to change the fragmenter "on the fly." Should this be
a solrconfig/schema setting?
It
On 5/2/07, Brian Whitman <[EMAIL PROTECTED]> wrote:
Would love to set a custom fragmenter in Solr for highlighting. But I
don't see a way to change the fragmenter "on the fly." Should this be
a solrconfig/schema setting?
It would be nice to able to register custom format
: don't see a way to change the fragmenter "on the fly." Should this be
: a solrconfig/schema setting?
yeah, it would probably make sense if there was a way to specify that in
the config ... i'm not really sure exactly how it shoudl work though since
i don't relaly use highlighting ... on one han
Would love to set a custom fragmenter in Solr for highlighting. But I
don't see a way to change the fragmenter "on the fly." Should this be
a solrconfig/schema setting?
Mike Klaas wrote:
On 7/19/06, Andrew May <[EMAIL PROTECTED]> wrote:
(although I have
wondered whether it would be possible for the default highlighted
fields to be derived
from the query in some way).
It wouldn't be too hard to extract : queries in
StandardRequestHandler. Do you have anyth
On 7/18/06, Andrew May <[EMAIL PROTECTED]> wrote:
In CommonParams, the variables added for highlighting were declared static
(unlike the
existing variables for the field list etc.). I made these non-static and
everything still
compiles. Is that OK?
Thanks for pointing it out, I just fixed thi
On 7/19/06, Andrew May <[EMAIL PROTECTED]> wrote:
(although I have
wondered whether it would be possible for the default highlighted fields to be
derived
from the query in some way).
It wouldn't be too hard to extract : queries in
StandardRequestHandler. Do you have anything specific in mind
On 7/18/06, Chris Hostetter <[EMAIL PROTECTED]> wrote:
: Field properties could be made more than a convention... the
: f.field.property=val stuff could be parsed out to easier-to-use
: objects by PluginUtils. But they are optional, and I don't see
: f.foo.fragsize=0 being more complicated than
Chris Hostetter wrote:
certainly ... i'm just not clear if there are a lot of cases where that
much flexability is really needed at query time -- as opposed to in the
solrconfig where it can more easily be expressed.
I guess in my mind people are more likley to say "in this application,
anybody
: Field properties could be made more than a convention... the
: f.field.property=val stuff could be parsed out to easier-to-use
: objects by PluginUtils. But they are optional, and I don't see
: f.foo.fragsize=0 being more complicated than having to write your own
: custom query handler ;-)
cer
On 7/18/06, Chris Hostetter <[EMAIL PROTECTED]> wrote:
Adding a "namespace" of query params for dealing with highlighting (or
anything else) seems kind of complicated and confusing ... is that level
of granularity of control at query time really that usefull conpared to
the complexity of understa
: Have you considered making the query language an XML-base POST'd
: language, like updates? As the language increases in power, this
: could improve manageability. It would also correspond directly with
: directives in solrconfig.xml. A subset of the query language could be
: allowed in a GET
On 7/18/06, Yonik Seeley <[EMAIL PROTECTED]> wrote:
<>
I wonder what the default fragment size should be?
FWIW, the current default is 100 and this seems to do a decent job.
We should keep in mind that future Fragmenters might be able to be
more intelligent (take periods into account, for inst
This makes me think that perhaps I was taking the wrong tack by specifying the
Fragmenter
class, and that it would be better to specify the fragment length. If length <=
0 then use
the NullFragmenter, otherwise use the GapFragmenter, supplying the length value
to it.
This has the same issue of
Mike Klaas wrote:
My main comment before seeing the patch is that the Fragmenter desired
might be different for different fields. In my use, I'd want
GapFragmenter for the main text field and NullFragmenter for the title
field. This complexity is why I didn't implement this in the first
patch.
I just recently added some tasks to the wiki task-list related to highlighter:
* Allow specification of begin and end markup for highlighted
regions, perhaps with namespace like query params highlight.start=
highlight.end=
* Allow specification of default highlighter markup via init
params
On 7/18/06, Andrew May <[EMAIL PROTECTED]> wrote:
I've been trying out the highlighting added to Solr recently (thanks - it's
really
useful), and I found myself wanting to highlight entire fields rather than just
generating
fragments. i.e. I want to use the Lucene NullFragmenter rather than the
Hi,
I've been trying out the highlighting added to Solr recently (thanks - it's really
useful), and I found myself wanting to highlight entire fields rather than just generating
fragments. i.e. I want to use the Lucene NullFragmenter rather than the default GapFragmenter.
I've made some chang
18 matches
Mail list logo
