trackr_lookup: Backend-interface API

Description

This page describes the API which must be implimented by all Trackr backends Any class with methods for these generic can be used in the backend slot of a TrackrDB object. These functions should not be called directly by an end-user.

Usage

trackr_lookup(object, target, opts, exist = FALSE)
insert_record(object, id, target, opts, verbose = FALSE)
prep_for_backend(object, target, opts, verbose = FALSE)
remove_record(object, target, opts, verbose = FALSE)
trackr_write(target, opts, verbose = FALSE)
trackr_search(
  pattern,
  target,
  opts,
  fields = NULL,
  ret_type = c("doclist", "id", "backend"),
  verbose = TRUE
)

Arguments

object

ANY. The object to lookup, add, remove, etc.

target

ANY. The backend of the TrackrDB instance.

opts

TrackrOptions. The trackr-level options. Typically extracted from target in a TrackrDB method and passed down.

exist

logical. Return TRUE/FALSE rather than the looked-up object. (default: FALSE)

character. The id to assign to the recorded result within the target backend.

verbose

logical. Should extra informative messages be displayed ( default: FALSE)

pattern

character. A regular expression to match against the text in fields

fields

character or NULL. The fiends in which to match, or NULL to include all fields.

ret_type

character. Format in which to return the response. Options are: "id" - id of matching documents (default), "doclist" - A list containing the matching documents represnted as R lists, and "backend" - a backend specific representation of the set of matching documents (generally the same class as backend.

Value

for trackr_lookup: If exist is TRUE, a logical indicating whether object was found in db. Otherwise, the object stored in the database (or NULL if it was not found).

for insert_record and remove_record: The TrackrDB (db parameter) after the plot has been added or removed.

For prep_for_backend, object, representend in the form that the insert_record method for backend expects.

Details

Methods should be written to be dispatched on target, and, where appropriate on codeobject/codedoc

These methods should be endomorphic with respect to the target argument. That is, they should return an object of the same class as was passed to target, which reflect the requested change to the backend state.

insert_record may or may not involve writing to disk, which can alternatively occur during trackr_write. Writing, if any is desired, must occur within at one and only one of these methods. If insert_record performs the writing, trackr_write should be a no-op.