Every data team has a version of this story.
Let's say someone needs to rename a column. Maybe it was called cust_id and now it should be customer_id. Maybe amount needs to become amount_eur because the system now handles multiple currencies. Maybe a table is being deprecated and its columns redistributed across two new ones.
The question that follows: what else will break?
In some environments, the honest answer is: we're not entirely sure. There might be a handful of pipelines that reference that column explicitly. There might be a few more that reference it inside a SQL query. There might be a dashboard somewhere pulling from a view that joins on it. The column change is five minutes of work. Finding everything that depends on it is an afternoon, at best.
This is the problem that the RDBMS Impact plugin was built to solve. It scans your entire Apache Hop project, every pipeline, every workflow, every transform, and returns a complete inventory of database references. Which tables are used where. Which connections. Which transforms. Before you change anything.
But there's a gap.
RDBMS Impact captures explicit references, transforms where the table is defined directly in the metadata. A Table Output configured to write to orders. A Database Lookup pointing at customers. Those are easy to find because the table name is sitting right there in the transform configuration.
What it doesn't capture are implicit references, table names that appear inside SQL text. A Table Input with a hand-written query. An Execute SQL action running a stored procedure. A SELECT email FROM customers WHERE active = true buried inside a transform that, from the outside, just looks like a generic SQL executor.
The SQL Parser plugin exists to handle this. Feed it a SQL statement and it returns the schemas, tables, and columns that statement references. It doesn't execute the SQL, it parses it. The table list is extracted statically, without touching the database.
Together, the two plugins cover the complete surface area of a Hop project's database dependencies.
The pipeline we built, rdbms-impact-sql-parser, runs both in a single pass. RDBMS Impact scans the project and produces two types of rows: transforms with an explicit table reference, and transforms with embedded SQL. The first group flows straight to the output. The second group goes through SQL Parser first, which extracts the table and column references from the SQL text, and then flows to the same output, tagged with source = SQL so you know where the reference came from.
The result is a single table: column_change_impact, that you can query before making any schema change:
sql
source,
object_type,
object_name,
item_type,
item_name
FROM column_change_impact
WHERE table_name = 'customers'
AND column_name = 'cust_id';
If the result is empty, the change is safe. If it returns rows, you have a precise list of every pipeline, workflow, and transform that will be affected, and whether the reference was explicit in the metadata or hidden inside a SQL string.
This is what data governance looks like in practice. A pipeline you run before you make the change, that tells you exactly what you're dealing with.
Check the pipeline template on putki.io/templates.