Log4j provided and only Slf4j

Upgrades to Bullet Record 1.2.2

We now only have a compile time dependency on slf4j-api. The binding to log4j is marked as provided so dependent projects can use whatever logging implementation they want. If log4j is desired, then those projects can depend on the binding and mark it as as scope compile.

[BUGFIX] HASH function, type hinting support, fix for empty fields in TOP K

Upgrades to bullet-record-1.2.1 with type hinting (in supported versions of BQL).

Adds a HASH function to create hash codes for fields.

Fixes a bug that would cause an error for a Query if all the fields in a TOP K aggregation were empty strings.

Outer queries (subqueries) and lateral views explodes of lateral view explodes

This release adds the ability to run another query within a query. This is equivalent to running a subquery in SQL. The only current restriction is that the outer query cannot have a Window.

Lateral View's can now operate on a list of TableFunctors. This lets the LATERAL VIEW EXPLODE operation be applied to the result of another LATERAL VIEW EXPLODE field.

More efficient LateralView

This release allows for Core to allow operating on Booleans as numbers more efficient as well as changes how Lateral View is implemented - getting rid of unnecessary record copying for each Lateral View table operation.

Support Unknown as first class

Updates to Bullet Record 1.2.0 with support for unknown types. No other changes.

Bullet Record 1.1.4

Uses Bullet Record 1.1.4 with the fix for Avro record copying

ByteArrayPubSubMessageSerDe - for lazy storing of Query as byte[]

Adds a com.yahoo.bullet.pubsub.ByteArrayPubSubMessageSerDe. This behaves like the IdentityPubSubMessageSerDe except for when Queries are written out using the #toMessage(String, Query, String) interface, the resulting PubSubMessage stores a byte[] as its payload. The getContentAsQuery and getContentAsByte change the stored payload lazily to the resulting type. The net result is that this SerDe can be used to write Queries from the API as byte[] and it'll stay that way even if it's passed around multiple times as a byte[] till it's read as a Query.

This replicates the behavior of PubSubMessage queries before the SerDe infrastructure was introduced.

PubSubMessage stores Serializable. PubSubMessageSerDe to control ser/deser

This release:

• Modifies the PubSubMessage to store a Serializable content instead of byte[]. This makes it a lot more flexible rather than have to externally serialize some payload. The various constructors have been unified to take Serializable instead of byte[] (so they should still be compatible
• The JSON interface methods in PubSubMessage now Base64 encode payloads. If you customize PubSubMessages (e.g. with new Metadata classes), you can configure a Gson instance to deserialize it and pass it to PubSubMessage#fromJSON(String, Gson) to deserialize your custom data and hook into the Base64 decoding.
• Adds a PubSubMessageSerDe class to control how PubSubMessages are sent to and read. This is intended to be used to customize what is sent to and read in the backend. This can be used to implement lazy Query creation and other useful features.

New functions: MOD, LOWER, UPPER

MOD: Remainder after division (can be negative)
LOWER: Lowercases a string
UPPER: Uppercases a string

[BUGFIX] BulletConfig did not recreate the BulletRecordProvider if it was set after creation

The BulletRecordProvider was instantiated once after constructor and did not change if the setting for the class was changed in BulletConfig afterwards. This release doesn't change that behavior, however, it adds a BulletConfig#createBulletRecordProvider() method to always fetch the latest value for the setting and cache it so that future calls to getBulletRecordProvider() do return the up-to-date value.

This release also updates to bullet-record-1.1.3