run.query: Utility function that runs and returns an arbitrary database...
In ConvergenceDA/visdom: R package for energy data analytics

1 2	run.query(query, cfg, cacheDir = NULL, cacheFile = NULL, forceRefresh = F, debug = F)

`query`	a string representation of the SLQ query to be run.
`cfg`	a named list of connection configuration options, often loaded from a flat configuration file using `dbCfg`.
`cacheDir`	an optional directory path to a location where query results can be cached as RData for future use without querying the database again.
`cacheFile`	an optional file name that signals that the results of the query should be cached as RData using the passed cacheFile name. Note that if there already exists an RData file with that name in the cache directory, the contents will be returned without running the query. This it is imerative that the `cacheFile` names are unique to each unique query that should be run.
`forceRefresh`	an optional parameter for use when a `cacheFile` has been specified. If True (default is False), the query is run against the database with results overwriting any existing cached data. This is similar behavior to entering the cache directory and erasing the cached data before calling the `run.query` function.
`debug`	print out diagnostic information about the cache path, file, and status, along with the full text of any SQL query executed.

run.query is a utility function that is very often used in DataSource implementations. It automatically connects to a database with configuration that can be read from a config file, runs queries, and returns results as data.frames. It also supports caching of query results in a query cache directory, using passed cacheFile names, which must be carefully managed by the data source author to ensure that the cacheFile names are truly unique to each unique query made. For example, the cache file for query to load meter data for an individual meter would need to include the meter's id (or similar) to ensure that it isn't mistaken for data from another meter already cached. The purpose of all this cacheing logic is, of course, to improve the performance of data retrieval for large sets of data where query times can significantly impact performance. Thus it is often good practice to load and cache data in larger chunks than individual meter data.

dbDfg, conf.dbCon

ConvergenceDA/visdom documentation built on May 6, 2019, 12:51 p.m.