interface-api: Backend-interface API

In gmbecker/recordr: Semantic Annotation and Discoverability System for R-Based Artifacts

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)
id	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.

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.

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.

Note

remove_record should have the same writing behavior as insert_record

remove_record should have the same writing behavior as insert_record

gmbecker/recordr documentation built on May 24, 2021, 10:59 a.m.