Creating a core with automatic resource generation 

An existing CQL table is required to create a core with automatic resource generation. Options are available to generate resources automatically.

The prerequisite for creating a core with automatic resource generation is an existing CQL table. DSE Search automatically generates default solrconfig.xml and schema.xml files that are based on the table metadata. You can generate resources automatically, using an HTTP POST request or a dsetool command and the generateResources option. The following list describes the options for generating resources automatically:

dsetool syntax

The dsetool syntax for generating resources automatically and creating the Solr core is:

$ dsetool create_core keyspace.table generateResources=true [option ...]

User credentials can be provided in several ways, see Providing credentials for authentication.

The following example shows the dsetool method of automatically generating resources for the nhanes_ks keyspace and nhanes table that are used in the Tutorial: Basics:
$ dsetool create_core nhanes_ks.nhanes generateResources=true

By default, when you automatically generate resources, existing data is not reindexed. You can check and customize the resources before indexing.

See dsetool create_core for details on command options.

To override the default and reindex existing data, use the reindex=true option:

$ dsetool create_core nhanes_ks.nhanes generateResources=true reindex=true

DataStax Enterprise uses the type mapping in Mapping of Solr types to generate the CQL-based core and resources. To generate resources automatically, the CQL table can consist of keys and columns of any CQL data type. However, decimal and varint are indexed as strings. Lucene does not support the precision required by these numeric types. Range and sorting queries do not work as expected if a table uses these types.

Note: Use the simplest and best fit Solr types to fulfill the required type for your query. Review the generated schema.xml and solrconfig.xml, and adjust types to the simplest Solr type.
DocValues are column-oriented indexes. The values of DocValue fields are densely packed into columns instead of sparsely stored like they are with stored fields. DocValues are a way of recording field values internally that is more efficient for some purposes, such as sorting and faceting, than traditional indexing.
Note: Due to SOLR-7264, setting docValues=true on a boolean field in the Solr schema does not work. A workaround for boolean docValues is to use 0 and 1 with a TrieIntField.

To use DocValues, enable it for a field; define a field type and then define fields of that type with DocValues enabled in the schema file.

Note: If one or more nodes fail to create the core in distributed operations, an error message indicates a list of the failing node or nodes. Distributed operations fail if the core creation or core reload fails on one of the nodes. To solve the problem, follow the resolution steps in the error message. For example, if a core creation or core reload succeeds in all nodes except one, an error message suggests a core reload to solve the issue. The error message includes the failing node or nodes.

DocValues enabled by default 

Field cache is off by default.

The default behavior for auto-generated schemas enables DocValues for any fields of the following types:
  • Any Solr type extending TrieField
  • TrieDoubleField
  • TrieFloatField
  • TrieIntField
  • TrieLongField
  • Any Solr type extending UUIDField
  • TimeUUIDField
When DocValues are selected for all fields, or for specific fields, the following additional field types have DocValues applied to them:
  • Any Solr of type StrField or extending StrField
  • StrField
  • AsciiStrField
  • DecimalStrField
  • InetField
  • VarintStrField

This DocValues default behavior also applies to copyField destination fields that are of type StrField.

Note: Using spaceSavings profiles disables auto generation of DocValues.