Customize PubSub messages for publishing and storing using PubSubMessageSerDe

This release updates to Bullet Core 1.4.0 and Bullet BQL 1.2.2. You can now provide a PubSubMessageSerDe in your PubSub configuration file (by default uses the IdentityPubSubMessageSerDe which does nothing) if you want to customize how messages sent out to your PubSub (and not read from your PubSub) and stored in your Storage are structured. See pubsub_defaults.yaml for more information.

For instance, BQL 1.2.2 provides a LazyPubSubMessageSerDe that you can use if you do not want to send a full Query object to your PubSub or store it. The backend will need to be plugged in with the same SerDe which can recreate the Query object there. Note that in this case, the BQL in the Service will still run and produce a Query object but it will just be discarded.

Adds an API to add stored queries from QueryService

Adds a QueryService#get(String) to retrieve the stored PubSubMessage

Core 1.3.1 and BQL 1.2.0

This release updates to using Bullet Core 1.3.1 and Bullet BQL 1.2.0

First release using Screwdriver

No new changes

First release on Maven Central - Bintray EOL

Core 1.2.2. No new changes

Bullet Core 1.2.1

Updates Bullet Core to 1.2.1 and (all dependencies that use core to the the latest versions that use 1.2.1)

First Major Release - Expressions, PubSub changes, Storage, Async queries, no more JSON!

This release migrates Bullet to use Bullet Core 1.0 (specifically 1.2.0) and Bullet BQL 1.0 (specifically 1.1.0.

There are a lot of changes as part of 1.0 and this release is highly interface breaking. The following are the major highlights:

1. JSON queries are no longer supported! All queries must be sent in BQL, which has been enhanced significantly to support full, first-order SQL with arbitrary expressions. The various defaults provided to the backend with respect to queries are now provided to the Web Service instead and handled at the time of BQL query parsing. You can configure those defaults by providing a new yaml file to application.yaml (see the query section in the application.yaml).
2. The PubSub no longer transfers JSON queries and instead deals with serialized objects.
3. A Storage layer has been added that can be configured in the Web Service. This layer lets you store queries from the Web Service, which can then be re-read in backends that support it for resiliency. In the future, this layer will be used for more such as state for the UI, user concepts etc! To configure, see the storage section in application.yaml.
4. Endpoints:
   • A new asynchronous querying endpoint has been added (by default at /queries/async-query), where queries can be sent but results are sent to pluggable responders - these allow you to send Bullet query results to somewhere else like a PubSub or email or storage. To configure, see the async section in application.yaml.
   • The bql-to-json endpoint has been removed
   • A new validation endpoint has been added for validating BQL queries (by default at /queries/validate-query). This is used by the UI to validate raw BQL queries from the UI
   • All querying endpoints have by default been moved to serve with a /queries namespace. The namespaces are there to let you plug in security layers that can do path specific security. You might wish to do that for the admin namespace below.
   • There is a new replaying endpoint (by default at /admin/replay) that lets you send a signal to the backend to refresh its queries from the Storage layer.
5. The schema endpoint (still at /columns) has been modified to produce schema compatible with Bullet UI 1.0+. This new schema format was released as part of the included Bullet Record 1.0 (specifically 1.1.0). See the sample schema file for the default columns that are served if you do not provide one.
6. A new Metrics module has been added that lets you plugin metrics reporters for the various API endpoints status codes, errors and other signals (particularly relevant for asynchronous querying). You can use this to send metrics periodically to some external metrics collection system. See the metrics section in .application.yaml on how to write and set up one.

Query Service API updates

This release is an internal change to add more API touchpoints to the QueryService. This is primarily useful for those wrapping the Bullet WS. User facing behavior should be unchanged.

It adds or renames:

1.void submitSignal(String, Signal) no longer removes the query. See killQuery for that
2. void submitMessage(PubSubMessage) submits an arbitrary PubSubMessage to the backend
3. boolean failQuery(String) simply fails the query without sending anything to the backend
4. QueryHander killQuery(String) sends a KILL signal to the backed but does not fail
4. boolean hasQuery(String) returns true iff the query exists
5. QueryHander getQuery(String) returns the query if it exists
6. QueryHander removeQuery(String) removes and returns the query if it exists
7. killRunningQueries -> failAllQueries to be consistent with what failQuery does

Uses bullet-bql-0.2.1

This release updates BQL to 0.2.1 allowing you to use extended field access notation for BQL as well.

BQL to JSON endpoint, handles dead backend, supports new types in Schema, Bullet Core 0.6.4

This release:

1. Adds a new endpoint to convert BQL back to JSON. You can customize the name here.
2. Queries submitted when the backend is down keep hanging. A new reaper thread to clean up such stale queries when the backend is down has been added. This reaper thread works by sending a simple query to the backend every configurable ms and uses that as the test. You can configure that (including disabling it) here
3. The schema service now supports all the complex types available in Bullet Record - Float, Integer, Map of Maps, Lists of Primitives etc.

Closes #18, #23, #25.