[ckan-dev] Issue with new Solr Schema + faceting with extras

Thu Dec 8 13:35:46 UTC 2011

On 8 December 2011 13:04, Rufus Pollock <rufus.pollock at okfn.org> wrote:
> 2011/12/8 Adrià Mercader <amercadero at gmail.com>:
> With facet fields you almost always want string ... (you can try some
> slightly fancier stuff e.g. ignore case and strip whitespace but I
> don't think it is worth the effort).
I agree

> Note also that facet fields and query fields almost always want to be
> separate in the solr schema for that reason. A standard convention is
> to take any standard field and have facet field name {fieldname_facet}
> -- since what you want to facet is somewhat configurable this usually
> has to be setup in client code. As an example of this see the dynamic
> facet field in the openspending schema:
>
> https://github.com/okfn/openspending/blob/master/solr/openspending_schema.xml#L221
>
> (It is OpenSpending client code that creates the contents of these
> facet fields of course).
This is an interesting approach, we could use the already existing
"search.facets" option to add the appropriate "XX_facet" fields from
the CKAN indexing code.
But this is just yet another schema change, and right now you can
achieve the same faceting by the catch-all field (using "extraname"
instead of "extras_extraname")

> This also speaks to the longstanding issue of, at least in the API and
> all externally facing interfaces, having the extras in the main
> namespace (i.e. not having some 'extra' subdictionary or 'extra'
> prefix on the field names. See http://trac.ckan.org/ticket/1240
I'm not in principle against this, but I'm curious about the benefits
of it. Having extras separated gives you an idea of what's part of the
CKAN core model (so likely to be stable) and what is
project-dependent. (But perhaps this is a too CKAN-centric point of
view)


Adrià