SolrList object makes Solr data accessible through a
list-like interface. This interface is appropriate when the data are
SolrList should more or less behave analogously to a list. It
provides the same basic accessors (
tail, etc) and
can be coerced to a list via
as.list. Supported types of
data manipulations include
An obvious difference between a
SolrList and an ordinary list
is that we know the
SolrList contains only documents, which are
themselves represented as named lists of fields, usually vectors of
length one. This constraint enables us to provide the convenience of
accessing fields by slicing across every document. We can pass a field
selection to the second argument of
[. Like data frame,
selecting a single column with e.g.
x[,"foo"] will return the
field as a vector, filling NAs whereever a document lacks a
value for the field.
The names are taken from the field declared in the schema to
represent the unique document key. Schemas are not strictly required
to declare such a field, so if there is no unique key, the names
Field restrictions passed to e.g.
may be specified by name, or wildcard pattern (glob). Similarly, a row
index passed to
[ must be either a character vector of
identifiers (of length <= 1024, NAs are not supported, and this
requires a unique key in the schema) or a
but note that if it evaluates to NAs, the corresponding rows are
excluded from the result, as with
subset. Using a
SolrExpression is recommended, as
filtering happens at the database.
SolrList can be made lazy by calling
defer on a
SolrList, so that all column retrieval, e.g., via
SolrPromise object. Many operations on
promises are deferred, until they are finally
being shown or through explicit coercion to an R vector.
A note for developers:
common functionality through the base
Solr class. Much of the
functionality mentioned here is actually implemented as methods on the
These are some accessors that
SolrList adds on top of the
basic data frame accessors. Most of these are for advanced use only.
ndoc(x): Gets the number of documents (rows); serves as an
nfield(x): Gets the number of fields (columns); serves as an
ids(x): Gets the document unique identifiers (may
NULL, treated as rownames); serves as an abstraction
fieldNames(x, ...): Gets the name of each field represented by
any document in the Solr core, with ... being passed down to
core(x): Gets the
SolrCore wrapped by
query(x): Gets the query that is being constructed by
Most of the typical data frame accessors and data manipulation
functions will work analogously on
Details). Below, we list some of the non-standard methods that might
be seen as an extension of the data frame API.
rename(x, ...): Renames the columns of
where the names and character values of ... indicates the
newname = oldname).
defer(x): Returns a
SolrList that yields
SolrPromise objects instead of vectors
whenever a field is retrieved
searchDocs(x, q): Performs a conventional document
search using the query string
q. The main difference to
filtering is that (by default) Solr will order the result by
score, i.e., how well each document matches the query.
Constructs a new
SolrList instance, representing a Solr
core located at
uri, which should be a string or a
RestUri object. The
... are passed to the
eval(expr, envir, enclos): Evaluates R language
enclos as the
as.data.frame(x, row.names=NULL, optional=FALSE, fill=FALSE):
Downloads the data into an actual data.frame, specifically an
FALSE, only the fields represented in at least one document are
added as columns.
as.list(x), as(x, "DocCollection"): Coerces
the corresponding list, specifically an instance of
SolrFrame for representing a Solr collection as a
table instead of a list
1 2 3 4 5 6 7 8 9 10 11
Add the following code to your website.
For more information on customizing the embed code, read Embedding Snippets.