lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yonik Seeley" <yo...@apache.org>
Subject Re: listing/enumerating field information
Date Sat, 20 Jan 2007 04:34:50 GMT
On 1/19/07, Erik Hatcher <erik@ehatchersolutions.com> wrote:
> So, where are we with these things now?
>
> On Jan 11, 2007, at 2:24 AM, Tracey Jaquith wrote:
> > 1) across the entire index, enumerate all the unique values for a
> > given field.
>
> &facet=true&facet.field={fieldname} can do this with the standard
> request handler.  Right?
>
> The one delta for my use case is getting ones that start with a
> certain prefix.  I'll look into adding this when I can.
>
> > 2) we use unrestricted dynamicField additions from documents.
> > (that is our users are free to add any named field they like to
> > their document's data (which is metadata for their item)).  we want
> > to list all the unique field names in the index.
>
> I think a standalone request handler to return all the field names in
> the index would be great.  Anything this thing should return other
> than a list of field names?  I think this should be standalone
> because it is separate from a search, and in my use case it would be
> something solrb would load up once (per connection to Solr perhaps)
> and use to dynamically show what can be faceted on, sorted on,
> searched on, etc.  Combine that with a fetch of schema.xml, and a
> client would have a pretty good picture of what is under the covers.
> Maybe the request handler that returns the field names could also
> combine that with the schema information, flattened a bit.
>
> Thoughts?

The code for most of these things is easy... the hardest part is
coming up with interfaces flexible enough that you don't box yourself
in later and make things ugly.

For example, how does one specify a prefix constraint while faceting a field:

facet.field=myfield&f.myfield.terms=foo*

But what if you also wanted to facet a different way on the same field
in the same request?
When we came up with per-field params for highlighting, it worked well
because everything was field based.  It no longer really is.

One could use (abuse) the per-field-param capability to do something like:

facet.id=1
f.1.field=myfield
f.1.terms=foo*
facet.id=2
f.2.field=myfield
f.2.terns=bar*

I'm not impressed.  I'm leaning toward being practical (punting and
going with the first form for now... the upshot being that you can't
facet on the same field multiple ways.)

Thoughts?

-Yonik

Mime
View raw message