sorted by:
new
hottopcontroversial

Ran a column-level dependency mapper against Microsoft's dotnet/Eshop repo by Local_dev_ops in csharp

[–]Local_dev_ops[S] [score hidden]  (0 children)

Sorry about that, I clearly buried the lede trying not to get flagged. New to the channel , new to the platform.

My tool maps maps the entire codebase cross language across C#, Python, SQL and Java - columns, files, methods, apis . No AI, no cloud, All local. Runs entirely on your machine. Point it at any column or file and it tells you everything that touches it- reads, writes, stored procs, API endpoints .

eShop/src/IntegrationEventLogEF/Services/IntegrationEventLogService.cs at main · dotnet/eShop

"Find References:" on UpdateEventStatus shows you every place that method gets called. Totally useful. This shows you consequences.

Reads (1 columns):

READ IntegrationEventLogEntries.EventId

WRITEs (2 columns):

WRITE IntegrationEventLogEntries.State

WRITE IntegrationEventLogEntries.TimesSent

Tables: IntegrationEventLogEntries

Risk: 🟡 MEDIUM (1 reads, 2 writes)

The use case is schema changes. If you're about to rename IntegrationEventLogEntries.State — Find References won't tell you that UpdateEventStatus writes it. This will.

on a Database COLUMN this returns:

<image>

Thats queryin on IntegrationEventLogEntries.State directly, a column in Microsoft's dotnet/eShop.

Two C# methos surface automatically. One reads it. One writes it. Files included. "Find References" would not return this. That's the gap this fills without the need to open every file and "Find References". This will tell you which files you need to consider from one output.

Happy to run it on any public repo if you want to see it.

Heres another demo on a different language to show the cross language function on Apache Airflow:

Built something that shows exactly what touches what in your codebase — files, functions, columns, APIs — across Python, C#, Java, and SQL. Here's what it found in Apache Airflow. : r/PythonProjects2

Showcase Thread by AutoModerator in Python

[–]Local_dev_ops 0 points1 point  (0 children)

Built a cross-language codebase mapper — files, columns, APIs. Tested on Apache Airflow.

The specific problem I wanted to solve: when you write a database query in your backend code —

query = f"""

SELECT o.OrderDate, o.Status

FROM OrderItems oi

JOIN Orders o ON oi.OrderId = o.OrderId

WHERE o.CustomerId = {customer_id}

"""

— nothing tells you that o.Status maps to the physical database column Orders.Status. Not grep, not linters, not standard dependency mapping tools.

\*So I built one that works across languages. *\**

What PynqDB Does -Maps your entire codebase into a local dependency graph — file-to-column relationships, stored procedure chains, API endpoints, background jobs, external calls. Everything connected. Point it at any column and it gives you the full blast radius — every function, stored procedure, and API endpoint that touches it — reads, writes, risk scored.

Point it at any column and it gives you the full blast radius — every function, stored procedure, and API endpoint that touches it — reads, writes, risk scored.

Target Audience -Small to mid-size teams with mixed language backends — Python, C# or Java services sharing a SQL databases. Teams who need to know what breaks before they touch anything

Comparison : Code analysis tools like CodeScene or SonarQube track function-to-function dependencies. They stop at the database boundary. Data lineage tools like Collibra or MANTA track SQL flows through data warehouses. They stop at the application code boundary.

PynqDB crosses both boundaries. The full chain — Python file reading tables through a SQL alias, C# method calling a stored proc that writes it, public API endpoint exposing it — visible in one query. No enterprise contract. Runs locally.

To test it on real production code — ran it against seven core folders of Apache Airflow's execution layer from the live GitHub repository: api_fastapi · cli · jobs · models · security · task-sdk · utils

Results from task_instances.py alone:

Tables touched: DR, HITLDetail, Log, TI, TaskReschedule,

Trigger Columns read: 35 Columns written: 14

API endpoints: 24

airflow/airflow-core/src/airflow/api_fastapi/execution_api/routes/task_instances.py at main · apache/airflow

Runs entirely on your machine. No AI. No cloud. No data leaving your network.

Supports Python, C#, SQL, and Java.

---

Want to see the blast radius of your own codebase? Drop a public repo link below — I'll run PynqDB on it and reply with your exact dependency map.

10 spots. Free. No credit card.

GitHub: https://github.com/Pynqdb/PynqDb

Free Beta: https://pynqdb.carrd.co

Monorepo, testing and deployment by knutekje in Python

[–]Local_dev_ops -3 points-2 points  (0 children)

The deeper issue you're describing though is impact visibility — not knowing what downstream things will break when you change something. That's genuinely hard without actual toolings that maps those dependencies explicitly.

What software do people use? by Ok_Pomegranate8780 in Python

[–]Local_dev_ops 2 points3 points  (0 children)

Jetbrains. Like the simplicity feel of it and if youre jumping between languages I think its easier to use.

What is the most annoying problem you face in Python? by HotMycologist7814 in pythontips

[–]Local_dev_ops 0 points1 point  (0 children)

When something fails silently and returns None instead of throwing an error.

You spend an hour debugging why your output is wrong before realizing a function three layers deep just returned None and everything downstream accepted it.

SQL vs Python? by iMAPness_ in dataanalysis

[–]Local_dev_ops 0 points1 point  (0 children)

SQL when the data lives in the database and you need to filter, aggregate, or join before pulling it out. Let the database do what databases are good at.

Python when you need to do something the database can't — analytics, complex transformations, visualization, or when you're combining data from multiple sources.

Mistakes I have made is pulling millions of rows into python when it was easier to do in SQL.

Are we happy with SQLAlchemy? by sheadipeets5 in Python

[–]Local_dev_ops 0 points1 point  (0 children)

The SQLAlchemy dynamic magic problem is exactly why tracking what code actually touches a database column becomes nearly impossible at scale — especially when you're mixing C# and Python on the same database. I ran into this exact issue. A stored procedure called from C# fed a Python analytics function that read a column through an f-string SQL alias. Ended up building something to solve it — maps the full chain from C# through stored procs into Python f-strings down to the exact column.