The competitor that is missing from prior art
The prior art section lists Metanome, schema visualisers, and hand-written scripts. It leaves out the one most people would actually reach for first: reading the application code.
Somebody landing in a legacy Rails, Django or Spring codebase does not have lost relationships. They are in models.py, in has_many, in @ManyToOne. The database declares nothing, the application declares everything, and reading it is free.
Not naming that is a credibility gap. A reader who thinks of it before we do concludes we did not.
The honest answer, which is also a better pitch
The ORM tells you what the application intends. It does not tell you that 1,284 rows of os_servico point at a technician who does not exist. Those are different questions, and the second one is where this tool has no substitute — the ORM is the thing that let the orphans in.
So the positioning is:
- If your application declares the relationships, read the code. It is faster and it is authoritative about intent.
- This tool is for when it does not — a vendor system with no source, a database that outlived three rewrites, logic that lives in PL/pgSQL, a dump handed to a consultancy with nothing else — or for when you need to know whether the data actually obeys, which no model file can tell you.
What to change
- Add the ORM to prior art, honestly, as the strongest alternative for the discovery half of the problem.
- State the two audiences plainly near the top, instead of implying the tool is for every old Postgres database.
- Lead the integrity half harder.
BROKEN is the part nothing else answers, and it is currently framed as one of three verdicts rather than as the thing that has no competitor.
A tool that knows who it is for earns more trust than one that implies it is for everyone.
The competitor that is missing from prior art
The prior art section lists Metanome, schema visualisers, and hand-written scripts. It leaves out the one most people would actually reach for first: reading the application code.
Somebody landing in a legacy Rails, Django or Spring codebase does not have lost relationships. They are in
models.py, inhas_many, in@ManyToOne. The database declares nothing, the application declares everything, and reading it is free.Not naming that is a credibility gap. A reader who thinks of it before we do concludes we did not.
The honest answer, which is also a better pitch
The ORM tells you what the application intends. It does not tell you that 1,284 rows of
os_servicopoint at a technician who does not exist. Those are different questions, and the second one is where this tool has no substitute — the ORM is the thing that let the orphans in.So the positioning is:
What to change
BROKENis the part nothing else answers, and it is currently framed as one of three verdicts rather than as the thing that has no competitor.A tool that knows who it is for earns more trust than one that implies it is for everyone.