Create a plumber router based on any table specification

[azimov]

This PR adds some functionality to server up very basic result models. This is still a work in progress as there needs to be a lot more functionality to support adding end points that allow custom queries more easily.

SImilarly, it would be good to extend the data model descriptions to support foreign keys. This would allow the creation of automatic links between different tables within the spec. However, a csv/single table to store this is likely painful to work with so this will not happen until it can be well designed.

[azimov]

@ablack3 I would appreciate your input on this as this is a very basic stab at implementing something we discussed before in terms of serving up Plumber apis of projects. I intended this be written in a way that can be extended by adding additional end points etc. Naturally, this functionality doesn't touch at all how results will actually be hosted.

[codecov[bot]]

Codecov Report

Merging #34 (b19ead4) into develop (35ef1d0) will increase coverage by 0.16%. The diff coverage is 95.89%.

@@             Coverage Diff             @@
##           develop      #34      +/-   ##
===========================================
+ Coverage    93.62%   93.79%   +0.16%     
===========================================
  Files            8        9       +1     
  Lines          910      983      +73     
===========================================
+ Hits           852      922      +70     
- Misses          58       61       +3     

Files Changed	Coverage Δ
R/QueryNamespace.R	100.00% <ø> (ø)
R/PlumberRouter.R	95.89% <95.89%> (ø)

[ablack3]

Thanks @azimov. I'm a actually not very familiar with ResultModelManager so I might not be much help here. I would like to use it at some point but haven't had the chance to use it on any projects. I guess the idea here is to offer a rest endpoint for pulling results from a database which seems like a good idea in general. Maybe @mdlavallee92 has some comments. Sorry I'm not more help here!

[mdlavallee92]

No additional comments from me, tbh I am not very knowledgeable in restAPI or when to use them appropriately. Adding a comment more to get a sense of where you are taking this package @azimov.

My understanding of RMM (please correct me @azimov) is this helps migrate the data from the analytic into a state where it can be displayed into a shiny app for instance. The migration being key in terms of binding data from the various databases, ensuring the field names and attributes are consistent and forming stability of the rectangular object. Each analytic (CohortGenerator, FeatureExtraction) has its own migration. These are all saved to a sql lite object that we target to build a shiny app of, correct?

Now for the plumber piece, Would adding this layer allow me to request for a different view of this rectangular object (like a pivot or a mutation)? Or is it more simple in terms of specifying which table I want to view from the sqlite object. Apologies if this is totally off base 😅

[azimov]

@mdlavallee92 the migrations are one part of this package, but the overall goal is to provide a standard set of utilities for dealing with results data sets across OHDSI packages. You're pretty much right about the migrations part, but the results don't have to be in sqlite. We generally support postgres internally at JNJ. Sqlite just allows people to deploy apps without requiring any infrastructure.

The general idea behind this PR was that it would make accessing the data simpler in reports or situations where querying the data set isn't possible. For example, exposing the results of a study to the world. Working with APIs would also make the shiny apps a bit more manageable as you can spawn separate async javascript requests rather than having blocking database queries.

However, i think its still a bit too basic to be useful on its own right now...