Skip to content

v1.7.2

  The Schedules Release

Minimum Supported ThoughtSpot version

Unchanged. ThoughtSpot 10.0.1 and later.

Minimum Supported Python version

Unchanged. Python 3.9.2 and later.

Check out the highlights of our latest CS Tools release!

A focused release. Searchable gains an opt-in view of your Liveboard schedules, the TML library catches up with ThoughtSpot Cloud, and two reported bugs are fixed. Nothing changes unless you ask for it: every existing command runs exactly as it did in 1.7.1.

searchable metadata can now extract your Liveboard schedules and their run history, so you can answer how many schedules exist, which are paused, which stopped running, and which ones fail.

The extract is opt-in. Add --include-schedules to your existing command and nothing else changes.

cs_tools tools searchable metadata --syncer "snowflake://..." --include-schedules --config ENV:
  • TS_SCHEDULE holds one row per schedule per extract date, so a schedule's history accumulates under any load strategy.
  • TS_SCHEDULE_RUN holds one row per run with its status and error detail. ThoughtSpot keeps about 30 days of run history, so a regular extract builds the longer record for you.
  • searchable deploy creates both tables and their joins to TS_CLUSTER and TS_ORG.
  • A page the cluster cannot answer logs a warning and the extract keeps what it already fetched.

CS Tools now requires thoughtspot_tml 2.4.5, which was regenerated from the current ThoughtSpot spec. TML carrying viz_style, author, obj_id, ai_tile and the other recent attributes loads and deploys again, with no changes to your files.

Upgrading to 1.7.2 with cs_tools self update pulls the new library in automatically.

  • On Windows, a run with its output redirected to a file, such as a scheduled task or a CI step, no longer exits 1 after a fully successful extract. The phase markers in the log lines are plain ASCII now.
  • scriptability checkpoint exports each object once. An object published to several Orgs used to come out once per Org, under the same GUID. Thank you to the community for the report and the fix.
  • cs_tools self sync upgrades only the packages it names. It used to let the resolver move every dependency underneath them as well, which overrode the pinned command-line library and left every command failing on startup. If a sync already broke your installation, cs_tools self update repairs it.
  • New installations stay on SQLAlchemy 2.0. SQLAlchemy 2.1 dropped a package CS Tools depends on, so a 1.7.1 installation made on or after October 6 fails on every command, including self update. If that is you, reinstall with the installer's --reinstall flag and you land on 1.7.2. The Snowflake dialect does not support SQLAlchemy 2.1 yet either.
Breaking Changes

None. The schedules extract is opt-in, and every fix in this release ships with tests that pin the behavior.