Query namedtuple object was using a `defaults` option introduced in Python 3.7. This release supports earlier python3 versions
- Webapp is now able to parse a JSON body sent to `v2/results` endpoints
- Puts back support for `v1/<query_name>` style endpoints for results for now (with deprecation note in README)
- Makes `/reports` discovery endpoints `v2`-only
- Bump alpine base image version
- add git executable for gitpython dependency
- pin gunicorn for compatibility with alpine py3-gevent package
While there was much to love about Kenneth Reitz's 'Responder' framework, it was ultimately pulling in too many dependencies, for reasons that Nerium doesn't really need. I decided to stick with Flask for the foreseeable future, and this release rewrites `app.py` using Flask.
There is also a significant change to the public web API. This was unrelated to the Flask move, and in fact implemented on Responder first before porting over:
🎉 The release adds "discovery" endpoints:
- list reports available on the server
- get a description of each report by name, including columns returned, parameters expected, and other metadata if provided
See README for more details. Here, note that it was impossible to add these without changing the URL paths to distinguish between discovery endpoints and report results endpoints. Base paths are now:
- `/v1/reports/<name>` for discovery endpoints
- `/v1/results/<name>` for reporting results (formerly the whole app)
Query metadata formatting
Instead of using the `frontmatter` library and making query files a mashup of SQL and YAML, as of this release YAML metadata should be placed in a multiline comment, with a special `:meta` label introducing the comment. Again, usage is covered in the README
Remove plugin architecture for other query types
The library portion of Nerium had a fair amount of logic—some of it arguably verging on indirection and cruft—devoted to the idea that we might some day support non-SQL query languages, either by adding more `nerium.resultset` modules, or allowing third parties to provide `nerium-*` plugins. This was probably hurting performance, was certainly hurting maintainability, and the use case for it was speculative at best. This release drops all that, in favor of a single `db` module, using SQLAlchemy. Output formats can still be customized, with Marshmallow schemas.
I was always a little embarrassed by using `munch` for the query object. Replaced that with `SimpleNamespace` which is StandardLibrary now, and nicer in other respects.
Avoids some issues between responder and starlette by pinning starlette ourselves, because responder doesn't. Easier than the workarounds I've been suggesting in https://github.com/OAODEV/nerium/issues/38
- Implement formatting using marshmallow schemas
- Provide for custom formats via additional schemas in format_files directory
This one is pretty cool, if I do say so myself. (I do.)
[Responder](https://python-responder.org) is the framework Nerium was waiting for, and I wish I'd thought of [marshmallow](https://marshmallow.readthedocs.io) for formats in the first place. I was thinking about maybe using jinja templates for that, until I came across a Stack Overflow comment that (correctly) pointed out the risk of generating invalid JSON that way. Marshmallow was made for the task.
If you've been using Nerium, you should upgrade.
Fixes an invalid Framework classifier that had been added to setup.py and was causing PyPI to reject the release upload.
No changes to public (web-facing) API. Plugin architecture for resultset query types and formatters simplified.
- Remove abstract base classes
- Rewrite query and formatter modules without class inheritance
- Remove jinja-sql resultset
- Move `resultset` and `formatter` packages directly under `nerium` instead of `contrib`
- Remove query and formatter class lookup maps from config; we can do this with more straightforward naming conventions now
- query file extension matches resultset module name directly
- same with `ne_format` URL param and formatter modules
* Add frontmatter and config file handling
- Move ResultSet and ResultFormatter subclass mappings to global config
- Allow backend database to be specified in frontmatter, config, or envar
- ResultSet classes take a query object (muncihfied dict) that holds query body and metadata attributes
- Handle ResultSet dispatching in query module
- Parse out frontmatter from query files and add to Query object
- Pass through frontmatter metadata to formatter classes
- Currently no formatter uses frontmatter yet, tho default passes it to response
- Support arbitrary key-value metadata to describe results to clients
- Can use frontmatter to specify database backend per query file in this release
* Create a summary result formatter which can automatically separate out summary and normal result rows when using [Postgres GROUPING functions](https://www.postgresql.org/docs/current/static/functions-aggregate.htmlFUNCTIONS-GROUPING-TABLE) in a query
* Updates to README.md via tym-oao
* Increase test coverage
- Fixed a small bug in Dockerfile: installing from local setup.py was failing to build because README doesn't get copied into the image. Changed to install latest with `pip` instead.
- Added `pipenv` install instruction in README.md
First version uploaded to PyPi
- API as documented in README
- dependencies all included in setup.py
- Dockerfile for Docker Hub
- Command `nerium` starts local aiohttp server with nerium.app