Currently we assign release version number in release branches and
master was still pointing to some old version number from when the
process was different. We need a dummy version number that both setuptools
and npm are ok with.
* Initial test
* Save
* Working version
* Use since/until from payload
* Option to prefix metric name
* Rename LineMultiLayer to MultiLineViz
* Add more styles
* Explicit nulls
* Add more x controls
* Refactor to reuse nvd3_vis
* Fix x ticks
* Fix spacing
* Fix for druid datasource
* Rename file
* Small fixes and cleanup
* Fix margins
* Add proper thumbnails
* Align yaxis1 and yaxis2 ticks
* Improve code
* Trigger tests
* Move file
* Small fixes plus example
* Fix unit test
* Remove SQL and Filter sections
* Fix percent_metrics ZeroDivisionError and can not get metrics with label issue
* convert iterator to list
* get percentage metrics with get_metric_label method
* Adding tests case for expression type metrics
* Simplify expression
* Make port number optional in superset for druid
It appears that urllib throws error with ssl if port number is provided
```
url = "https://example.com:443/druid/v2"
req = urllib.request.Request(url, druid_query_str, headers)
res = urllib.request.urlopen(req)
```
The above call fails with the following error:
```
urllib2.HTTPError: HTTP Error 404: Not Found
```
If url is set to https://example.com/druid/v2 it works, this change
makes the port number optional.
* Rewrite if/else in concisely python way
* [WiP] make MetricsControl the standard across visualizations
This spreads MetricsControl across visualizations.
* Addressing comments
* Fix deepcopy issue using shallow copy
* Fix tests
* [sql lab] a better approach at limiting queries
Currently there are two mechanisms that we use to enforce the row
limiting constraints, depending on the database engine:
1. use dbapi's `cursor.fetchmany()`
2. wrap the SQL into a limiting subquery
Method 1 isn't great as it can result in the database server storing
larger than required result sets in memory expecting another fetch
command while we know we don't need that.
Method 2 has a positive side of working with all database engines,
whether they use LIMIT, ROWNUM, TOP or whatever else since sqlalchemy
does the work as specified for the dialect. On the downside though
the query optimizer might not be able to optimize this as much as an
approach that doesn't use a subquery.
Since most modern DBs use the LIMIT syntax, this adds a regex approach
to modify the query and force a LIMIT clause without using a subquery
for the database that support this syntax and uses method 2 for all
others.
* Fixing build
* Fix lint
* Added more tests
* Fix tests
* Force lowercase column names for Snowflake and Oracle
* Force lowercase column names for Snowflake and Oracle
* Remove lowercasing of DB2 columns
* Remove DB2 lowercasing
* Fix test cases
