---
title: "Details on biodb"
author: "Pierrick Roger"
date: "`r BiocStyle::doc_date()`"
package: "`r BiocStyle::pkg_ver('biodb')`"
vignette: |
  %\VignetteIndexEntry{Details on general *biodb* usage and principles}
  %\VignetteEngine{knitr::rmarkdown}
  %\VignetteEncoding{UTF-8}
abstract: |
  Provides some more advanced knowledge on *biodb*: OOP model, configuration,
  request scheduler, persistent cache, logging...
output:
  BiocStyle::html_document:
    toc: yes
    toc_depth: 4
    toc_float:
      collapsed: false
  BiocStyle::pdf_document: default
bibliography: references.bib 
---

```{r, echo=FALSE}
source(system.file('vignettes_inc.R', package='biodb'))
```

# Introduction

In this document are presented different aspects of *biodb* in more details:
the object oriented programming model adopted,
its architecture,
how to configure the package,
how to create connectors and delete them,
understanding the request scheduler,
how to tune the logging system.

# Object oriented programming (OOP) model

In R, you may already know the two classical OOP models *S3* and *S4*.
*S4* is certainly the most used model, and is based on an original system of
generic methods that can be specialized for each class.

Two more recent OOP models exist in R: *Reference Classes* (aka *RC* or *R5*
from package *methods*) and *R6* (from package *R6*).
These two models are very similar.
The *biodb* package uses a mix of *RC* and *R6*, but will switch completely to
*R6* in a near future.

They both implement an object model and based on references.
This means that each object is unique, never copied and accessed through
references.
In this system, the created objects are not copied, but their reference are
copied.
Any modification of an object in one part of the code, will be visible from all
other parts of the code.
This means that when you pass an instance to a function, that function is able
to modify the instance.

Also, in *RC* and *R6*, the functions are attached to the object.
In other words, the mechanism to call a function on a object is different from
*S4*.
The calling mechanism is thus slightly different, in *RC* or *R6* we write
`myObject$myFunction()` instead of `myFunction(myObject)` in S4.

See
[Reference Classes](https://www.rdocumentation.org/packages/methods/versions/3.6.0/topics/ReferenceClasses) chapter from package *methods*
and this [introduction to R6](https://r6.r-lib.org/articles/Introduction.html)
for more details.

# Initialization & termination

*biodb* uses an initialization/termination scheme. You must first initialize
the library by creating an instance of the main class `BiodbMain`:
```{r}
mybiodb <- biodb::newInst()
```
And when you are done with the library, you have to terminate the instance
explicitly:
```{r}
mybiodb$terminate()
```

We will need a *biodb* instance for the rest of this vignette. Let us call the
constructor again:
```{r}
mybiodb <- biodb::newInst()
```

# Management classes

Several class instances are attached to the *biodb* instance for managing
different aspects of *biodb*: creating connectors, configuring *biodb*,
accessing the cache system, etc.

See table \@ref(tab:mngtClasses) for a list of these instances and their
purpose.

Class                 | Method to get the instance      | Description
--------------------- | ------------------------------- | --------------------------------
BiodbConfig           | `mybiodb$getConfig()`           | Access to configuration values, and modification.
BiodbDbsInfo          | `mybiodb$getDbsInfo()`          | Databases information (name, description, request frequency, etc).
BiodbEntryFields      | `mybiodb$getEntryFields()`      | Entry fields information (description, type, cardinality, etc).
BiodbFactory          | `mybiodb$getFactory()`          | Creation of connectors and entries.
BiodbPersistentCache  | `mybiodb$getPersistentCache()`  | Return an instance of fscache::Cache that manages a cache system on disk.
BiodbRequestScheduler | `mybiodb$getRequestScheduler()` | Send requests to web servers, respecting the frequency limit for each database server.
: (\#tab:mngtClasses) The management classes.
Only one instance is created for each of theses classes, and attached to the `BiodbMain` instance,

# Configuration

Several configuration values are defined inside the `definitions.yml` file of
*biodb*.
New configuration values can also be defined in extension packages.

o get a list of the existing configuration keys with their current value, run:
```{r}
mybiodb$getConfig()
```

To get a data frame of all keys with their title (short description), type and
default value, call (result in table \@ref(tab:keysDf)):
```{r}
x <- mybiodb$getConfig()$listKeys()
```
```{r keysDf, echo=FALSE, results='asis'}
knitr::kable(x, "pipe", caption="List of keys with some of their parameters")
```

To get the description of a key, run:
```{r}
mybiodb$getConfig()$getDescription('useragent')
```

To get a value, run:
```{r}
mybiodb$getConfig()$get('useragent')
```

To set a field value, run:
```{r}
mybiodb$getConfig()$set('useragent', 'My application ; wizard@of.oz')
mybiodb$getConfig()$get('useragent')
```

If the field is boolean, you can use the following methods instead:
```{r}
mybiodb$getConfig()$enable('offline')
mybiodb$getConfig()$disable('offline')
```

Configuration keys have default values. 
You can get a key's default value with this call:
```{r}
mybiodb$getConfig()$getDefaultValue('useragent')
```

Environment variables can be used to overwrite default values.
To get the name of the environment variable associated with a particular key,
call the following method:
```{r}
mybiodb$getConfig()$getAssocEnvVar('useragent')
```

# Databases information

Before creating any connector, you can information on the available databases
and their connector classes.

Getting the databases info instance will print you a list of all available
database connector classes:
```{r}
mybiodb$getDbsInfo()
```

If you want more information on one particular connector, run:
```{r}
mybiodb$getDbsInfo()$get('mass.csv.file')
```

# Accessing a custom CSV file with a biodb connector

When creating a connector with `CompCsvFileConn` or `MassCsvFileConn`, if your
CSV file uses standard biodb field names as column names in its header line,
then everything will be fine and all values will read, recognized and set into
entry objects.

However if your CSV file uses custom column names, those values will be ignore
by biodb.
To tell biodb to use those columns, you must define a mapping between each
custom column with a valid biodb entry field, by using the `setField()` method.

Here we create a connector to a CSV file database (see table
\@ref(tab:compTable) for content) of chemical compounds that uses the semi-colon
as a separator:
```{r}
compUrl <- system.file("extdata", "chebi_extract_custom.csv", package='biodb')
compdb <- mybiodb$getFactory()$createConn('comp.csv.file', url=compUrl)
compdb$setCsvSep(';')
```
We use the `getUnassociatedColumns()` method to get a list of custom column
names:
```{r}
compdb$getUnassociatedColumns()
```
The method returns 3 column names that have not been automatically mapped.
However there is a little trick here, since `mass` field has been automatically
mapped but with the wrong biodb field `molecular.mass`, as you can see when
calling the method `getFieldsAndColumnsAssociation()`:
```{r}
compdb$getFieldsAndColumnsAssociation()
```
The `mass` column of the CSV file stores in fact the monoisotopic masses.
So we need to remap this column, and before that to reset the connector:
```{r}
mybiodb$getFactory()$deleteConn(compdb)
compdb <- mybiodb$getFactory()$createConn('comp.csv.file', url=compUrl)
compdb$setCsvSep(';')
compdb$setField('accession', 'ID')
compdb$setField('kegg.compound.id', 'kegg')
compdb$setField('monoisotopic.mass', 'mass')
compdb$setField('molecular.mass', 'molmass')
```

Now the connector works fine, and we can for instance get a list of all
accession numbers:
```{r}
compdb$getEntryIds()
```

And get whichever entry we want:
```{r}
compdb$getEntry('1018')$getFieldsAsDataframe()
```

```{r compTable, echo=FALSE, results='asis'}
compDf <- read.table(compUrl, sep=";", header=TRUE, quote="")
# Prevent RMarkdown from interpreting @ character as a reference:
compDf$smiles <- vapply(compDf$smiles, function(s) paste0('`', s, '`'), FUN.VALUE='')
knitr::kable(head(compDf), "pipe", caption="Excerpt from compound database CSV file.")
```

# Request scheduler

The `BiodbRequestScheduler` instance is responsible for sending requests to web
server, taking care of respecting the frequency specified by the `scheduler.n`
and `scheduler.t` parameters, and for receiving results and saving them to cache.

The cache is used to give back a result immediately without contacting the
server, in case the exact same request has already been run previously.

You do not have to interact with the request scheduler, it runs as a back end
component.

# Entry fields information

The `BiodbEntryFields` instance stores information about all entry fields
declared inside definitions YAML files.

Get the entry fields instance:
```{r}
mybiodb$getEntryFields()
```

Get a list of all defined fields:
```{r}
mybiodb$getEntryFields()$getFieldNames()
```

Get information about a field:
```{r}
mybiodb$getEntryFields()$get('monoisotopic.mass')
```
The object returned is a `BiodbEntryField` instance.
See the help page of this class to get a list of all methods you can call on
such an instance.

# Persistent cache system

The persistent cache system is responsible for saving entry contents and
results of web server requests onto disk, and reuse them later to avoid
recontacting the web server.

Run the following method to get the instance of the `BiodbPersistentCache`
class:
```{r}
mybiodb$getPersistentCache()
```

Do delete all entries of a connector from the persistence cache, run:
```r
conn$deleteAllEntriesFromPersistentCache()
```
After that we need to delete entry instances from memory with the following
call:
```r
conn$deleteAllEntriesFromVolatileCache()
```
Note that the results of web server requests are still inside the cache folder.
In order to force a new downloading of data, we need to erase those files too.
The following call will erase all cache files associated with a connector,
including the files deleted by `deleteAllEntriesFromPersistentCache()`:
```r
conn$deleteWholePersistentCache()
```

# Logging messages

*biodb* uses the *lgr* package for logging messages.
The *lgr* instance used by *biodb* can be gotten by calling:
```{r}
biodb::getLogger()
```
See the [lgr](https://s-fleck.github.io/lgr/) home page for demonstration on
how to use it.

You can use the following *biodb* short cuts to send messages of different
levels.
To send an information message:
```{r}
biodb::logInfo("%d entries have been processed.", 12)
```
To send a debug message:
```{r}
biodb::logDebug("The file %s has been written.", 'myfile.txt')
```
To send a trace message:
```{r}
biodb::logTrace("%d bytes written.", 1284902)
```

In addition *biodb* defines two methods to throw an error or a warning and log
this error or warning at the same time.
These are `biodb::error()` and `biodb::warn()`.

By default the *lgr* package displays information messages.
If you want to silence all messages, just run `lgr::lgr$remove_appender(1)`.
This is will remove the default appender and silence all messages from all
packages using *lgr*, including *biodb*.
However if you just want to silence *biodb* messages, run:
```{r}
biodb::getLogger()$set_threshold(300)
```
Information messages are now silenced:
```{r}
biodb::logInfo("hello")
```
For enabling again:
```{r}
biodb::getLogger()$set_threshold(400)
```
And messages are echoed again:
```{r}
biodb::logInfo("hello")
```

# Closing biodb instance

Do not forget to terminate your biodb instance once you are done with it:
```{r}
mybiodb$terminate()
```

# Session information

```{r}
sessionInfo()
```

# References