Preparing for CRAN submission

.Rbuildignore

@@ -1,8 +1,13 @@
+extras
+java-src
+license_header_stub.txt
+pom.xml
 ^.*\.Rproj$
 ^\.Rproj\.user$
 .travis.yml
 .classpath
 .project
+^cran-comments.md$
 build
 build.xml
 deploy.sh

DESCRIPTION

@@ -1,8 +1,8 @@
 Package: SqlRender
 Type: Package
 Title: Rendering Parameterized SQL and Translation to Dialects
-Version: 1.1.6
-Date: 2016-07-20
+Version: 1.1.7
+Date: 2016-08-07
 Author: Martijn J. Schuemie and Marc A. Suchard
 Maintainer: Martijn Schuemie <[email protected]>
 Description: This is an R package for rendering parameterized SQL, and

README.md

@@ -10,7 +10,7 @@ Features
 - Supports a simple markup syntax for making SQL parameterized, and renders parameterized SQL (containing the markup syntax) to executable SQL
 - The syntax supports defining default parameter values
 - The syntax supports if-then-else structures
-- Has functions for translating SQL from one dialect (Microsoft SQL Server) to other dialects (Oracle, PostgreSQL, Amazon RedShift)
+- Has functions for translating SQL from one dialect (Microsoft SQL Server) to other dialects (Oracle, PostgreSQL, Amazon RedShift, Microsoft PDW)
 
 Examples
 ========

SqlRender.Rproj

@@ -14,4 +14,5 @@ LaTeX: pdfLaTeX
 
 BuildType: Package
 PackageInstallArgs: --no-multiarch --with-keep.source
+PackageCheckArgs: --as-cran
 PackageRoxygenize: rd,collate,namespace

cran-comments.md

@@ -0,0 +1,18 @@
+This is the first submission of this package
+
+---
+
+## Test environments
+* Ubuntu 14.04.3 LTS (Travis), R 3.2.3
+* Windows 7, R 3.2.3
+
+## R CMD check results
+
+There were no ERRORs or WARNINGs. I see ? NOTES (on Travis):
+
+* CRAN New submission
+
+
+## Downstream dependencies
+
+This is a new submission, there are no downstream dependencies.

license_header_stub.txt

@@ -1,6 +1,6 @@
 # @file {FILE_NAME}
 #
-# Copyright 2014 Observational Health Data Sciences and Informatics
+# Copyright 2016 Observational Health Data Sciences and Informatics
 #
 # This file is part of SqlRender
 # 
@@ -25,7 +25,7 @@
  *
  * This file is part of SqlRender
  *
- * Copyright 2014 Observational Health Data Sciences and Informatics
+ * Copyright 2016 Observational Health Data Sciences and Informatics
  * 
  * Licensed under the Apache License, Version 2.0 (the "License");
  * you may not use this file except in compliance with the License.

vignettes/UsingSqlRender.Rmd

@@ -28,15 +28,6 @@ knitr::opts_chunk$set(
 
 This vignette describes how one could use the SqlRender R package. 
 
-# Installation instructions
-SqlRender is maintained in a [Github repository](https://github.com/OHDSI/SqlRender). It can be downloaded and installed from within R using the `devtools` package:
-
-```{r tidy=TRUE,eval=FALSE}
-install.packages("devtools")
-library("devtools")
-install_github("ohdsi/SqlRender")
-```
-
 # SQL parameterization
 One of the main functions of the package is to support parameterization of SQL. Often, small variations of SQL need to be generated based on some parameters. SqlRender offers a simple markup syntax inside the SQL code to allow parameterization. Rendering the SQL based on parameter values is done using the `renderSql()` function.
 
@@ -107,7 +98,7 @@ SQL for one platform (e.g. Microsoft SQL Server) will not always execute on othe
 
 A first limitation is that **the starting dialect has to be SQL Server**. The reason for this is that this dialect is in general the most specific. For example, the number of days between two dates in SQL Server has to be computed using the DATEDIFF function: `DATEDIFF(dd,a,b)`. In other languages one can simply subtract the two dates: `b-a`. Since you'd need to know a and b are dates, it is not possible to go from other languages to SQL Server, only the other way around.
 
-A second limitation is that currently only these dialects are supported as targets: **Oracle**, **PostgreSQL**, **Microsoft PDW (Parallel Data Warehouse)**, with some support for **Amazon Redhift**.
+A second limitation is that currently only these dialects are supported as targets: **Oracle**, **PostgreSQL**, **Microsoft PDW (Parallel Data Warehouse)**, and **Amazon Redhift**.
 
 A third limitation is that only a limited set of translation rules have currently been implemented, although adding them to the [list](https://github.com/OHDSI/SqlRender/blob/master/inst/csv/replacementPatterns.csv) should not be hard.
 
@@ -187,7 +178,7 @@ SELECT * FROM a EXCEPT SELECT * FROM b                      -- EXCEPT
 String concatenation is one area where SQL Server is less specific than other dialects. In SQL Server, one would write `SELECT first_name + ' ' + last_name AS full_name FROM table`, but this should be `SELECT first_name || ' ' || last_name AS full_name FROM table` in PostgreSQL and Oracle. SqlRender tries to guess when values that are being concatenated are strings. In the example above, because we have an explicit string (the space surrounded by single quotation marks), the translation will be correct. However, if the query had been `SELECT first_name + last_name AS full_name FROM table`, SqlRender would have had no clue the two fields were strings, and would incorrectly leave the plus sign. Another clue that a value is a string is an explicit cast to VARCHAR, so `SELECT last_name + CAST(age AS VARCHAR(3)) AS full_name FROM table` would also be translated correctly. To avoid ambiguity altogether, it is probable best to use the ```CONCAT()``` function to concatenate two or more strings.
 
 ## Temp tables
-Temp tables can be very useful to store intermediate results, and when used correctly can be used to dramatically improve performance of queries. In Postgres, PDW and SQL Server temp tables have very nice properties: they're only visible to the current user, are automatically dropped when the session ends, and can be created even when the user has no write access. Unfortunately, in Oracle temp tables are basically permanent tables, with the only difference that the data inside the table is only visible to the current user. This is why, in Oracle, SqlRender will try to emulate temp tables by
+Temp tables can be very useful to store intermediate results, and when used correctly can be used to dramatically improve performance of queries. In Postgres, PDW, RedShift and SQL Server temp tables have very nice properties: they're only visible to the current user, are automatically dropped when the session ends, and can be created even when the user has no write access. Unfortunately, in Oracle temp tables are basically permanent tables, with the only difference that the data inside the table is only visible to the current user. This is why, in Oracle, SqlRender will try to emulate temp tables by
 
 1. Adding a random string to the table name so tables from different users will not conflict.
 2. Allowing the user to specify the schema where the temp tables will be created.