Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>As karmajunkie alludes to, Sunspot uses its own standard schema. I'll go in to how that works in a bit more detail here.</p> <h3>Solr Schema 101</h3> <p>For the purposes of this discussion, Solr schemas are mostly comprised of two things: type definitions, and field definitions.</p> <p>A <code>type</code> definition sets up a type by specifying its name, the Java class for the type, and in the case of some types (notably text), a subordinate block of XML configuring how that type is handled.</p> <p>A <code>field</code> definition allows you to define the name of a field, and the name of the type of value contained in that field. This allows Solr to correlate the name of a field in a document with its type, and a handful of other options, and thus how that field's value should be processed in your index.</p> <p>Solr also supports a <code>dynamicField</code> definition, which, instead of a static field name, lets you specify a pattern with a glob in it. Incoming fields can have their names matched against these patterns in order to determine their types.</p> <h3>Sunspot's conventional schema</h3> <p>Sunspot's schema has a handful of <code>field</code> definitions for internally used fields, such as the ID and model name. Additionally, Sunspot makes liberal use of <code>dynamicField</code> definitions to establish naming conventions based on types.</p> <p>This use of field naming conventions allows Sunspot to define a configuration DSL that creates a mapping from your model into an XML document ready to be indexed by Solr.</p> <p>For example, this simple configuration block in your model…</p> <pre><code>searchable do text :body end </code></pre> <p>…will be used by Sunspot to create a field name of <code>body_text</code>. This field name is matched against the <code>*_text</code> pattern for the following <code>dynamicField</code> definition in the schema:</p> <pre><code>&lt;dynamicField name="*_text" type="text" indexed="true" stored="false" multiValued="true"/&gt; </code></pre> <p>This maps any field with the suffix <code>_text</code> to Sunspot's definition of the <code>text</code> type. If you take a look at Sunspot's schema.xml, you'll see many other similar conventions for other types and options. The <code>:stored =&gt; true</code> option, for example, will typically add an <code>s</code> on that type's suffix (e.g., <code>_texts</code>).</p> <h3>Modifying Sunspot's schema in practice</h3> <p>In my experience with clients', and my own, projects, there are two good cases for modifying Sunspot's schema. First, for making changes to the <code>text</code> field's analyzers based on the different features your application might need. And, second, for creating brand new types (usually based on the text type) for a more fine-grained application of Solr analyzers.</p> <p>For example, widening search matches with "fuzzy" searches can be done with matches against a special text-based field that also uses linguistic stems, or NGrams. The tokens in the original <code>text</code> field may be used to populate spellcheck, or to boost exact matches. And the tokens in the custom <code>text_ngram</code> or <code>text_en</code> can serve to broaden search results when the stricter matching fails.</p> <p>Sunspot's DSL provides one final feature for mapping your fields to these custom fields. Once you have set up the <code>type</code> and its corresponding <code>dynamicField</code> definition(s), you can use Sunspot's <code>:as</code> option to override the convention-based name generation.</p> <p>For example, adding a custom <code>ngram</code> type for the above, we might end up processing the body again with NGrams with the following Ruby code:</p> <pre><code>searchable do text :body text :body_ngram, :as =&gt; 'body_ngram' end </code></pre>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload