Skip to main content

​
What’s new in Liberator 2.6

Liberator 2.6 lets you onboard a REST API as a dataset. You can start from an OpenAPI or Swagger spec, a Postman collection, a JSON config file, or an endpoint you enter by hand. Entitlement reports can now answer who had access on a past date and include access granted through dataset groups. Disabling a user now removes their query access as well as their sign-in. Liberator now adds query capacity automatically during heavy load, and the release includes a broad set of query, caching, and connection reliability fixes.

​
Highlights

REST API onboarding

Create a dataset from an OpenAPI or Swagger spec, a Postman collection, a JSON config, or a manually entered endpoint.

Historical entitlement reporting

Report on who had access to a dataset on a past date, including access granted through dataset groups.

Indexes during discovery

See the indexes on a database table while onboarding, so you can choose date and key columns that query quickly.

Automatic scaling

Liberator adds query capacity when workers are busy or queries are waiting, then scales back down when load drops.

​
REST API onboarding

Create Dataset now accepts a REST API as a source. Choose how you want to describe the API:
  • OpenAPI / Swagger. Provide a spec URL, upload a YAML or JSON file, or paste the spec. Swagger 2.0 and OpenAPI 3.x are supported. Liberator lists the endpoints in the spec and you choose which ones become datasets. Pagination, query parameters, and response columns are read from the spec where it defines them.
  • Postman collection. Provide a Postman share link or upload an exported collection (v2.x). Liberator lists the requests, keeping your folder structure, and you choose which ones to onboard. Collection and environment variables such as {{baseUrl}} are resolved or prompted for. Saved example responses are used to suggest columns.
  • JSON upload. Upload or paste a connector configuration that describes endpoints, query parameters, pagination, and partitioning. Use this to reuse a configuration or to define one outside the UI.
  • Manual endpoint. Enter the endpoint, method, and parameters yourself.
Each method is validated before anything is saved, and invalid input is rejected with an error that points to the field at fault. You can review and edit the generated configuration before saving the dataset.

​
Entitlement reporting

  • Historical entitlements. Ask the Reporting tab who had access to a dataset, or what a user could access, as of a past date.
  • Dataset group access. Entitlement reports now include access granted through dataset groups, alongside access assigned directly to a user or through a user group.
  • Correct dataset lists. An entitlement report for an admin with access to every dataset no longer shows “All datasets” on every row. Each row now names the dataset.
See AI-based reporting.

​
Administration

  • Disabling a user removes query access. Previously, a disabled user could not sign in to the UI, but their entitlements remained and they could still query datasets through the API. Disabling a user now removes those entitlements as well.
  • Webhooks require an onboarding schedule. Enabling a webhook on a dataset now requires an onboarding schedule, because the statistics a webhook delivers are produced by scheduled onboarding runs.
  • Concordance is off by default. Concordance runs only on datasets where it is turned on and given a schedule in the dataset configuration. Dataset health cards and liberator.metadata() return concordance results for those datasets.
  • Column description suggestions match whole words only. For example, “country code” no longer suggests a description about “count”.

​
Database onboarding

  • When you run discovery on a database table, Liberator shows the table’s indexes so you can choose date and key columns that query efficiently.
  • SQL Server databases with a hyphen in the name, such as sales-prod, can now be sampled and queried.
  • Partitions generated for SQL sources no longer overlap, and long-running SQL reads time out more reliably instead of hanging.

​
Automatic scaling under load

When large or many concurrent queries keep every query worker busy, later queries used to wait until a running query finished. Liberator now adds query servers automatically when workers are saturated or queries start to queue, and removes them again after the load has stayed low for a few minutes. A new server only receives queries once it is fully started, so scaling up does not cause failed requests. You do not need to change anything to use this. Scaling limits are set per environment by CloudQuant.

​
Reliability

  • A query whose date range contains no data now returns an empty result quickly instead of scanning the whole dataset.
  • Repeated queries for data that is already cached return faster, and are no longer regenerated after a cache hit.
  • A client that disconnects in the middle of a large query no longer stalls the next queries on that server.
  • OneDrive connections pick up a refreshed sign-in automatically after the previous token expires.
  • S3 connections that are limited to a folder prefix now mount correctly.
  • Temporary S3 throttling no longer takes a storage mount offline.
  • Scheduled onboarding no longer reruns repeatedly overnight.
  • Query timeouts for the AI assistant integrations (MCP) can be adjusted for your environment instead of being fixed at 120 seconds.

​
Compatibility

There are no breaking changes to the client libraries or to the dataset query surface. Two behavior changes may need action:
  • Datasets that relied on concordance without a schedule will stop refreshing concordance results until you turn it on and add a schedule.
  • Datasets with a webhook but no onboarding schedule need a schedule before the webhook can be saved again.