Skip to main content

v1.6.0

Discover the new features, logic changes, bug fixes, breaking changes, and known issues and limitations in Piiano Vault release v1.6.0.

New features​

  1. The data type endpoint /api/pvlt/1.0/ctl/types/{type} now supports PATCH for updating the custom transformers available on any type (builtin or custom).
  2. The CLI command datatype command has a subcommand update that invokes the new method.
  3. Adding a custom transformer to a type, builtin or custom, overrides the implementation of an existing transformer, if any, with the same name.
  4. Improved the error messages for bad requests (PV1012 error code). It now includes the exact reason for the error and path to the field or parameter that caused it.
  5. The Update collection property API now supports updating the is_nullable property of a property from false to true.
  6. Performance improvements for the List objects and Search objects APIs. The API remaining_count response field now has an upper limit of 100000 configurable by the PVAULT_SERVICE_MAX_PAGINATION_REMAINING_COUNT environment variable.
  7. A new Set license API is now available to set the license of the Vault.

Bug fixes​

  • Fix a bug where using AWS KMS with temporary credentials was handled incorrectly.

Breaking changes​

  1. The API remaining_count response field now has an upper limit of 100000 configurable by the PVAULT_SERVICE_MAX_PAGINATION_REMAINING_COUNT environment variable.
  2. The filter query param of the pruner API trasaction_ids_only value now changed to be transaction_ids_only to fix a typo.
  3. Vault now enforces the OpenAPI validations on all requests more strictly. This means that some requests that were previously accepted will now return an error. The following are the changes that were made:
    1. Previously, the API tolerated null as a JSON value for optional fields. Now, a field must explicitly define nullable: true in the OpenAPI to allow null as a value. Optional fields that receive null but don't have nullable: true will now return a PV1012 error with the reason Value is not nullable
    2. Previously, the API tolerated empty values in query params. e.g. ?reason=&page_size=&..., etc. Now, a query param must explicitly define allowEmptyValue: true in the OpenAPI to allow setting an empty value. Query params sent with an empty value that doesn't have allowEmptyValue: true will now return a PV1012 error with the reason empty value is not allowed
    3. Previously, the CLI & SDK set many client-side default values. The SDK and CLI have been updated not to send any missing/null value, and the server is responsible solely for setting defaults.
    4. Previously, the API tolerated unknown fields in JSON, and they were ignored. Now, models defined with additionalProperties: false in the OpenAPI will return a PV1012 error for unknown fields with the reason property "abc" is unsupported.
    5. Many previous error codes for bad-request were changed to return a consolidated PV1012 code that describes the error. A list of all the error codes that were changed:
      • PV1001 - The access reason is missing.
      • PV1002 - The access reason is invalid.
      • PV1008 - The collection name is invalid.
      • PV3081 - The query should not be empty.
      • PV3088 - Format preserve template does not exist.
      • PV3089 - Format preserve template requires different amount of properties.
      • PV3203 - Too many tags provided.
      • PV3208 - Query param "page_size" exceeds the maximum value allowed.
      • PV3209 - Query param "page_size" must be a positive integer.
      • PV3215 - Can't detokenize archived tokens.
      • PV3224 - Tokenize request should not be empty.
      • PV3225 - Token type is invalid.
      • PV3228 - Object should contain at least one of the options.
      • PV3229 - Object should contain exactly one of the options.
      • PV3235 - Invalid encryption type.
      • PV3248 - Invalid input object request index out of range.
      • PV3251 - Token tag is longer than 256.
  4. Javascript engine related
    1. The model for FunctionName used in the DataType model has been changed. It is now a string formatted as <bundle-name>.<function-name>.
    2. The transformers field of custom data types that are returned by Vault no longer contains the builtin transformers. It only contains the transformers that are defined on the custom type itself. Builtin transformers are still inherited from the base type, and can still be applied to properties of custom types, as before.

On this page