New features for discussion

New features for discussion and code review.

Each are in a separate commit so that we can cherry pick which we want and which we don't

1) Roxygenate dependencies.  

This is a maintenance change. Roxygenate dependencies were prefixed by 'R/'. This is unnecessary and can interfere with Roxygenate's collate process. Only needed when making documentation for the project so shouldn't effect end users. Tested it with roxygen2-3.0.0. Don't know if it breaks backwards compatibility with earlier versions of roxygen2.

2) Added an ElasticSearch Reader. 

ElasticSearch is a Lucene based indexer. When I am working with large datasets I often use an ElasticSearch cluster instead of a database since searching and retrieving data is MUCH faster than a database. Uses the RElasticSearch package. This is NOT a CRAN package, so don't know if it will interfere with travis-ci or submitting to CRAN. 

So this raises some philosophical questions:

a) Do we want to add new readers to ProjectTemplate? Adding them willy-nilly can lead to an expanding code base and a maintenance nightmare down the road. If we do want to add readers to the Project should we develop a process of reviewing and vetting proposed readers and publish it on the ReadMe? 

If we don't want to support new readers, we should add infrastructure so that users can add custom readers in their own project. This will minimize the number of forks people make just to add a reader of their own.

b) Do we want to allow dependencies on non-CRAN packages? Personally I like that github is becoming a viable option for package distribution and would like to encourage using packages from github. Any other views?

3) Fixed up the JDBC reader to behave in accordance with documentation. 

Documentation claims that the JDBC reader will work if the jar file is included in the CLASSPATH. This only worked if classpath was included in the .sql file but left empty. Leaving out the classpath setting resulted in NULL being passed to the JDBC connection and throwing an error. It makes sense to me that if the jar file is already included in CLASSPATH then requiring an empty classpath in the .sql file is redundant.

4) Added Heroku DB as a datasource. 

Heroku is a postgres DB but doesn't play nice with the RPostgreSQL package. Instead requires custom settings using a JDBC connection. I find it a pain to copy all of those custom settings into a .sql file with type = jdbc. So created a wrapper with type = heroku. Kind of related to the philosophical questions raised in 2), but since this is a wrapper for an already supported reader I don't think it is as big of a potential problem as adding a completely new reader type.

5) Added string interpolation to DB queries. 

This is probably the most controversial proposed feature. For me the big vision of ProjectTemplate is being able to bootstrap data analysis programmatically. This goes a long way to encouraging reproducibility in data science. 
Currently the process supports loading data from single sources and then munging the data. The problem is if the data needs to be loaded in multiple stages.

Here is my use case:

I store Tweet texts in an ElasticSearch index and I store meta-data for each Tweet in a DB table. I run a query against ElasticSearch to retrieve the Tweet IDs. I then run a query against the DB table using the IDs to retrieve the meta-data.

Currently, I would load the IDs from the ElasticSearch index and then munge the data. This requires me to write code to access and query the database in the munging script -- a real case of code duplication. What I would like is to read the data from the ElasticSearch index and then use that data in the .sql file to make the query against the database, bootstrapping my final dataset from multiple sources.

My solution is to add string interpolation to the query term in the database reader:

query: SELECT * FROM my_table WHERE id IN (@{paste(ids, collapse=',')})

As long as the ElasticSearch data is loaded before this command there is no problem. For simple multistep data loading it is not hard to order the data files by hand.

If this feature seems like a good idea and we want to go further with multi-step data loading, the next step would be to add decencies to the data files so that the data loader can work out the order to load data files.

Looking forward to your thoughts!

PS Apologize for all the changes in the man/ directory. It looks like roxygenize removed lots of leading spaces :)