Zingg 0.7.0: A More Stable, More Usable Zingg

Zingg 0.7.0 is out. This release strengthens what’s running underneath Zingg - clearer errors when something breaks, and notebooks that are easier to work with day to day. Let’s go through what changed and what it means for your pipelines.

Improved Error Handling

Anyone who has debugged a failed Zingg job will appreciate this one.

Previously, exceptions thrown deep inside config loading and preprocessing could get wrapped in generic exceptions, losing the original message along the way. You’d see a wrapper exception with nothing useful underneath.

In 0.7.0, error propagation across config loading and preprocessing has been reworked so root-cause exceptions are chained properly into ZinggClientException and ZinggException, instead of being swallowed. When a job fails now, the exception you see is the exception you need, not a generic wrapper standing in for it.

Notebooks, Made Modular

We’ve also rethought how our example notebooks are structured, and this is one of the changes we’re most excited about in this release.

A typical end-to-end notebook walks through setup, labeling, document generation, and training/matching in one long sequential run. That’s fine the first time through  but it starts working against you the moment you want to relabel a batch of examples without re-running setup, or debug a matching issue without regenerating documents you already have.

In 0.7.0, our Databricks and Fabric notebooks have been split into numbered, single-purpose notebooks — one for setup, one for labeling, one for document generation, and one for training and matching. Each picks up where the previous one left off, so you can run and debug Zingg one stage at a time instead of working through a single monolithic notebook.

This borrows a principle straight out of software engineering: breaking a large, tangled unit of work into smaller pieces with clear boundaries makes the whole thing easier to test, easier to debug, and easier to hand off. The same logic that applies to splitting up a large function applies just as well to a notebook and it should make day-to-day work with Zingg noticeably smoother, whether you’re iterating on labels or debugging a training run.

GraphFrames 0.11.0 Upgrade

Zingg uses GraphFrames for connected component analysis, the step where pairwise match decisions get resolved into entity clusters. The upgrade to GraphFrames 0.11.0 brings the library current with upstream fixes and stability improvements. No code changes needed, this is transparent.

Docker Base Image Update

The Zingg Docker image now runs on apache/spark:3.5.5-python3, keeping the containerized environment aligned with the latest Spark patch release.

Bug Fixes

• Fixed the labeler UI truncating field values in vertical display mode.
• Corrected the documentation for the explain config.

Under the Hood

A couple of internal cleanups shipped in 0.7.0 that don't change user-facing behavior:

• Stale field removed: An unused name field was removed from Matcher and Linker.
• SparkClient constructors refactored: New overloads accept a zFactoryClassName string, making it easier to plug in a custom factory class.
• Test infrastructure split: The Spark test session is now split into Lite and Heavy profiles, so most tests run on a lightweight 1G session while only memory-intensive tests get the full 8G allocation. Performance test workflows were also consolidated into a single reusable GitHub Actions workflow.

Upgrading

pip install zingg==0.7.0

No API changes in this release, just a more stable foundation and clearer errors underneath.

You can browse the full diff and every PR on the v0.7.0 release page. Questions or feedback? Open a discussion on GitHub or find us in the community.

Zingg is open-source ML-based entity resolution, built on Apache Spark. Star us on GitHub if this is useful to you.