Graphtia documentation · workflow
Trace database uses in code
Follow supported static reads, writes and declarations between code and SQL tables, including uncertain matches.
What a code-to-table link means
Explorer recognizes bounded database operations in supported TypeScript/JavaScript and Python code, then compares their declared table identities with SQL sources in the indexed workspace. Read, write and declaration are different roles. A link is static evidence; it does not show that an operation actually ran.
Start from code or a table
Open API & DB → Database uses in code, or select a table and use its code action.
Filter by the owning code, table or SQL source when available; inspect the role and table/schema identity.
Open the owning symbol and the SQL declaration. Compare both source locations at the same revision.
For helper-based SQL, read the receiver/call context when present. Follow the proven source context rather than an unrelated function with the same name.
Keep inferred, unresolved and partial results explicit; follow pagination when available.
TypeScript and JavaScript
Supported driver forms include postgres, pg, better-sqlite3, mysql, mysql2 and mysql2/promise, with recognizable SQL and proven receiver provenance. Invocation-conditioned helper evidence starts from a proven postgres handle; other drivers do not automatically gain that coverage. A generic object with a query method is not automatically a database client. Shadowed imports, unknown receivers and SQL assembled at runtime can remain unresolved or unmodeled.
Python
Supported declarations include explicit Django Meta.db_table, SQLAlchemy __tablename__ and recognized Table calls with literal names. Supported reads/writes include bounded literal SQL wrapped in sqlalchemy.text and executed by a recognized Session. This is not general support for every Python DB-API driver or conditional helper chain. Dynamic imports, unknown sessions, nonliteral table/schema names and unsupported query constructs remain unresolved or unmodeled.
Keep possible declarations distinct
A name can match multiple SQL declarations. A unique match is an inferred source relationship, not proof of the same deployed database object. A missing match can reflect unsupported syntax, an out-of-scope SQL source or bounded inspection. A read/write observation can remain useful while its declaration target is unresolved.
Use it during a change
Changing a column: inspect its source declaration, candidate code uses and callers of the owning code.
Changing a query helper: inspect its proven receiver context and relevant invocation before attributing a table access.
Changing a handler: follow the API owner to supported database operations, then verify behavior with project tests.
Privacy and execution
The analysis does not connect to a database, execute SQL, load Python modules or request credentials. Returned source evidence may be shared with an external agent when you query through an integration; review that provider’s data settings.
Ask an agent
Use get_db_code_links to inspect supported uses in the selected workspace. Ask the agent to cite the owner, both source locations, role, revision and limitations. “No supported links returned” is not proof that the application never accesses that table.
