Skip to main content
Lucid.anda is a general framework for efficient traversal of data repositories with a rich set of configuration properties that allow fine-grained control of the kind, amount, and rate of data retrieval. Specific implementations have different configuration properties according to the repository type. To see which properties are required/optional, query the REST API via the URL: api/connectors/plugins/lucid.anda/types/CONNECTOR_TYPE. For example, see the lucid.anda-web plugin properties:

Basic configuration properties

The set of basic configuration properties limit the scope of the crawl. The crawler fetches the contents of the specified startLink property, adding any found links found. The connector adds nodes to a database known as crawldb to prevent re-processing. This database tracks indexed nodes as well as which nodes found to be redirects, duplicates, or otherwise aliases of another node. Regular expressions can restrict the crawl either by defining name patterns.

restrictToTree examples

Example 1: If your startLink value is https://altostrat.com, and this site has links to https://archive.altostrat.com and https://cymbalgroup.com, only documents at the domain https://altostrat.com are indexed. Example 2: Additional restrictToTree properties are described in Other configuration properties and include:
  • restrictToTreeAllowSubdomains - If false, all the startLink subdomains are excluded. If true, startLink subdomains are included.
  • restrictToTreeUseHostAndPath - If true, restrict the crawl to the startLink path.
  • restrictToTreeIgnoredHostPrefixes - Defines a list of startLink prefixes that are ignored during the crawl.
This example describes what is indexed if your startLink value is https://altostrat.com, restrictToTreeis set totrue and restrictToTreeAllowsubdomains is set to true or false. In the table:
  • The headings in columns 2 and 3 specify the settings of the fields.
  • A ✅ indicates the URL is indexed.
  • An ✘ indicates the URL is not indexed.

Fetcher Configuration Properties

Fetcher configuration properties vary by plugin. Fetcher configuration properties are distinguished by prefix “f.”, for example “f.maxSizeBytes”.

Content Filtering and Selection Configuration Properties

These properties are only used by the web plugin. Like the fetcher properties names, they have the prefix “f”.

Refresh Policy Configuration Properties

Refresh policies are used to control which items are recrawled, so they only matter on crawls after the first complete crawl, and the default refresh policy is to simply recrawl all items. The refreshAll property is true by default to create that behavior, so the first step in configuring a refresh-policy is to set refreshAll to false. There are five types of refresh policies: “refreshStartLinks”, “refreshErrors”, “refreshOlderThan”, “refreshIdPrefixes”, “refreshIDRegexes”. This is scriptable via a JavaScript function supplied as property “refreshScript”, for example:

Dedupe Configuration Properties

Fusion can be configured to deduplicate documents based on:
  • the entire contents of the document
  • the contents of a specified field
  • custom deduplication based on a document signature generated by a user-supplied JavaScript function genSignature() which returns a string. The Fusion UI Admin tool provides a JavaScript-aware input box which so that you can create and edit this function directly in Fusion.
Dedupe works by maintaining a signature for each document, and ensuring that exactly one document appears in Solr for each signature. It does this by designating the first document it encounters with a particular signature, making it the “canonical” document. All subsequent documents with that signature are designated as “aliases.” It keeps track of the current canonical document for a particular signature across crawls, and when a document signature changes, it maintains its guarantee that exactly one document with each signature shows up in Solr. In the case where custom deduplication is done either using a field or a custom signature, you must specify either the field or the JavaScript function, accordingly. The value of this string is found in the dedupeSignature_s field. If the property “dedupe” (UI control checkbox “Dedupe on Content”) is true but neither a field or JavaScript function are specified, the raw contents of the document are used for deduplication. No deduplication signature is generated, therefore the resulting document does not have a dedupeSignature_s field. Here is an example of a genSignature() function:
This example finds duplicates based on the h2 fields in each document. This script assumes that the h2 headers in the documents have been pulled into a field with the f.fieldSelectors property. The entire content object is available here, so implementations of this class can dedupe on any combination of fields. The genSignature() function should return null when the fields needed to generate a signature are not present.

Splitter Configuration Properties

These properties determine how to process .csv and .tsv files.

Other Configuration Properties

Property indexCrawlDBToSolr - index most recent crawldb in Solr

This section is only relevant to Fusion 4.x.
The boolean property indexCrawlDBToSolr when true, creates a Solr collection called crawldb_<data source-ID> which holds the crawldb for the most recently completed crawl. The default value is false. The crawl must finish. Nothing is recorded if a crawl is stopped. Restricting the contents of the Solr collection to the most recently completed crawl limits the collection from growing very large over time. It means that at the point where a data source is used to recrawl a website or filesystem, all information about previous crawls are deleted. The resulting Solr documents have the following fields:
  • id. The Solr uniqueKey field. The value is the concatenation of the map/table in the crawldb to which the doc belongs(see below), and the document ID. The two parts of the composite ID are separated by a | (gate/pipe) character. For example, the id of a document representing a FINISHED_MAP entry for a web page in a web crawl would look like: FINISHED_MAP|https://lucidworks.com/
  • crawlCycle_ti. The crawl iteration, for example, 1 for the initial crawl, 2 for the first recrawl, etc.
  • map_s. The map to which a document belongs in the crawldb
There are 6 kinds of information recorded:
  • ALIAS_MAP
  • INVERSE_ALIAS_MAP
  • FINISHED_MAP
  • ERRORS_MAP
  • SIGNATURES_MAP
  • DELETED_MAP
ALIAS_MAP is a mapping of all aliases (for example redirects in a web crawl, symlinks in a filesystem crawl, etc.) to their canonical targets. INVERSE_ALIAS_MAP is the opposite: a mapping of canonicals to all of their aliases. FINISHED_MAP is all items that have been successfully indexed. ERRORS_MAP is all errors. SIGNATURES_MAP will only be there if dedupe is enabled, and it is a mapping of long signature hashes to their canonical item-ID. DELETED_MAP is all of the docs that were deleted in Solr in the last crawl, for example 404s that have failed enough times to be deleted in a web crawl. FINISHED_MAP and ERRORS_MAP are the maps whose values are actual CrawlItem objects in the crawldb and have the same set of fields, of which the following are useful:
  • parentID_s
  • depth_ti
  • fetchedDate_tdt
  • emittedDate_tdt
  • lastModified_tdt
  • contentSignature_s
  • discardMessage_s
  • links_ss

Querying a crawldb Solr index

To see all errors with the exception that caused the error:
To see all deleted items with any exception that lead to deleting them:
To see all items discovered via links on a particular page:
To see all aliases of a particular page:
Find all pages fetched in the last 24 hours: