I needed to create additional documentation from my dbdiagram code. So I created a tool that converts the code to HTML tables. It may a feature that others need, so I have created a small demo to show case the feature. Note that the demo only supports a subset of the dbdoc language.
Hi Sam,
It is very nice to learn your work.
For your documentation use case, you may also try dbdocs.io. You could use the instructions found at Publish dbdiagram to dbdocs | dbdiagram Docs to publish your produced diagram to dbdocs.io.
Best regards,
David
Hi Dave,
Thanks for the feedback. I can see that dbdocs.io is a great documentation tool. When I created the parser for dbdiagram, I notices that the dbdiagram parser is more strict than I has to be. Examples:
[ref:>schema.table]
this works in my parser, but gives an error in dbdiagram.
[ref:>schema.table.column note: ‘this is a note’]
this works in my parser, but gives an error in dbdiagram. a comma between ref:>schema.table.column and note: ‘this is a note’ is actually not needed
[note: ‘note 1’]
[note: ‘note 2’]
In diagram only ‘note 2’ is included in the generated documentation. In my parser the result is note 1 + note 2.
table someTable {
note: ‘Note 1’
column varchar
}
Hi @sam_hepworth,
Thank you for taking the time to point out the differences,
[ref:>schema.table]
this works in my parser, but gives an error in dbdiagram.
Relationship requires a path to reach the correct column (usually in the form of schema.table.column). If only two names are given, then the schema name is assumed to be public, while the table name will be the first identifier (schema in your case) and the column name is the 2nd identifier (table in your case). If no such path to a column exists, an error is expected.
[ref:>schema.table.column note: ‘this is a note’]
this works in my parser, but gives an error in dbdiagram. a comma between ref:>schema.table.column and note: ‘this is a note’ is actually not needed
Besides note and ref, we also have other settings like primary key, not null,… and some have white space in them, without the comma to separate these settings, it would likely lead to many ambiguous cases, as well as being more difficult to read.
[note: ‘note 1’]
[note: ‘note 2’]
In diagram only ‘note 2’ is included in the generated documentation. In my parser, the result is note 1 + note 2.
Currently, multiple note definitions in a table are not yet supported, that why our parser simply overrides them with the last note.
I hope this explanation makes sense.