rest.li v0.15.1 Release Notes
-
- Main API change is removal/decoupling of validation from DataSchema. DataSchema no longer has validate method. The replacement is ValidateDataAgainstSchema.validate(...). ⬇️ Reduce memory allocation for DataElement for each object visited. Will reuse same DataElement for each member of a container. As part of this change, it is no longer possible to get a 🏗 standard Iterator from a builder. The alternative is to use the traverse method that takes a callback for each object iterated. ➕ Add support for different pre-order and post-order traversal to ObjectIterator. This allows ObjectIterator to be used for data to schema validation. This unification allows single pass data to schema validation as well as calling Validator after 🛠 fixup and schema validation. ✨ Enhance DataSchemaAnnotationValidator to not throw exception on construction. Allow validator to be used if only some validators are constructed. Use common Message classes for emitting 🎉 initialization messages. 🔨 Refactor code to allow both iterative and recursive validation. ➕ Add more test cases.
- ➕ Add support to taking DataElement as starting point for iterating through Data objects and for validation. This has been requested by Identity superblock where the patch is applied to position (using position as starting point), but the root object is a profile. The validation should start 🔌 where the patch is applied, but the validator plugin wants access to the entire entity, i.e. the profile entity. ➕ Add tests and bug fix unnecessary additional calls to validators from ValidateDataAgainstSchema when typerefs are in use. The 🐛 bug was that the downstream validator will be called once per 🛠 typeref in the typeref chain. The correct and fixed behavior is that the downstream validator will be called once per data object (not once per schema typeref'ed). 0.15 ➕ Add pluggable validator to Data Schemas
- Change behavior of ObjectIterator to include returning the input value. 👀 2. See com.linkedin.data.validator package and TestValidator class for how to use validators.
- This is still a prototype feature. Output Avro-compliant equivalent JSON from Pegasus schema ➕ Add translation between Pegasus DataMap and Avro GenericRecord 🔨 1. Also include refactoring of DataSchema to JSON encoding to move Avro specific code out of cow module into cow-avro module. ⚡️ Rest.li support for full and partial updates Full update (overwrite) is transported as an HTTP PUT to the entity URI, 🛰 with a payload containing the JSON serialized RecordTemplate of the entity schema. Partial update (patch) is transported as an HTTP POST to the entity URI, 🛰 with a payload containing a JSON serialized PatchRequest The internal structure of a PatchRequest is documented here: ⚡️ https://iwww.corp.linkedin.com/wiki/cf/display/ENGS/Partial+Update PatchRequests can be generated on the client side by "diff'ing" two RecordTemplate objects using PatchGenerator in com.linkedin.restli.client.utility. Patch Generation relies on the facilities from the data-transform pegasus 📦 component, in the com.linkedin.data.transform package. PatchRequests can be applied on the server side by providing a pre-image RecordTemplate object and a PatchRequest to PatchApplier in com.linkedin.restli.server.util. Patch application uses the DataMapProcessor from the pegasus data-transform component. ⚡️ Full and Partial update are provided as overloaded update() methods in CollectionResource/AssociationResource on the server-side and as overloaded ⚡️ buildUpdate() methods in EntityRequestBuilder on the client-side. ⚡️ PARTIAL_UPDATE is defined as a new ResourceMethod, and listed as appropriate 👍 in the IDL "supports" clause of the resource. 👌 Support for deep (nested) projections has been implemented: Server-side, the rest.li framework understands both the old "field1,field2,field3" 💅 syntax and the new PAL-style "field1,field2:(nestedfield)" syntax. Projections are applied automatically by the framework, using pegasus data-transform. ResourceContext provides access to the projections as either a Set or a MaskTree. Client-side, the generated RecordTemplate classes have been modified to provide fields as a nested class accessed through the .fields() static method. Each field can be accessed as a Path object through a fieldName() method, which provides full static typing. Fields are provided as methods rather than member variables to avoid initialization cycles when a RecordTemplate contains a field of the same type. Deep projection support is currently disabled on the client side, to avoid ordering 🚀 issues with deployment. Once all services have been deployed to production with the 🆕 new pegasus version, we will enable deep projections on the client side. 👍 More background on projection support is available here: https://iwww.corp.linkedin.com/wiki/cf/display/ENGS/Projections Compatibility: ⚡️ WIRE: This change is wire INCOMPATIBLE for existing users of update. There are ⚡️ no known uses of update in production. ⚡️ CLIENT: This change is library INCOMPATIBLE for users of update, projection fields, 🏗 or code that relies on the types of framework ...Builder classes (a type parameter has ⬆️ been removed). Client code will need to be upgraded. ⚡️ SERVER: This change is library INCOMPATIBLE for users of update. Server code will ⬆️ need to be upgraded to use PatchRequests and PatchApplier. 🔨 Validation code refactoring. 🚚 1. Move validation code out of DataSchema classes, enable single pass validation of schema and calling validator plugins. 📦 2. Move schema validation code into validation package. 📦 3. Move validator plugins into validator package.
- Provide field specific diagnostic data from schema validator. 📇 Rename cow and cow-avro module to data and data-avro module. 🔨 Refactor Cow classes and provide implementation that have the checker functionality but without copy-on-write, known as CheckedMap and CheckedList classes.
- ➕ Add support for "validate" annotation on fields. Prefix DataElement accessor methods with "get".
- ➕ Add support for filtering calls to a Validator based on what has been set as specified by the patch operations map. This functionality is implemented by the PatchFilterValidator class. Refactored ValidationMessage* classes into Message* classes so that patch operations can re-use these classes for generating patch messages.