[development] Let's finally document our schema already!
Angela Byron
drupal-devel at webchick.net
Thu Aug 9 06:02:25 UTC 2007
On 9-Aug-07, at 1:42 AM, Neil Drumm wrote:
> Documentation comments would be much better. They are in code, but
> have the advantage of not being code. The challenge is figuring out a
> convenient and consistent comment syntax.
As long as it's in-line with the schema source code, it doesn't
matter much to me what format it takes. But it **MUST** be in the
actual source code of the .schema file, and not stored in a separate
document (like the FAPI reference) or it will very quickly fall
hopelessly out of date with what the code actually says (like the
FAPI reference :P~).
In the meantime, though, we still do need the table/field
descriptions before we can do either one, so we can still work away
on that while we come to a consensus about the comment syntax.
Past attempts:
- http://drupal.org/node/28046: uses the MySQL COMMENT attribute,
limited to 60 characters. We can no longer use this method, because
we don't have actual SQL doing create table statements, and the
character limit sucked, anyway.
- http://drupal.org/node/79874: uses a common comment format ( --
(PK), -- (FK) -> session.sid, -- Description) to the SQL. Again,
we're no longer storing SQL, so this isn't viable, and it also shares
the fragile problem that regexing it out of the schema files has.
I'm having kind of a hard time making sense of this document, but I
"think" the "Putting documentation after members" section of the
Doxygen manual [http://www.stack.nl/~dimitri/doxygen/docblocks.html]
seems to have a special syntax for what kind of we're trying to do:
int var; /**< Detailed description after the member */
Of course, fields and tables aren't members of objects, but they are
"kinda sorta" the same thing. Meh, I dunno.
Open to other suggestions...
-Angie
More information about the development
mailing list