Maybe it is simpler (no parsing needed) to have an extra table with a
unique column holding tablename_fieldname
and a second column holding the comment for that field.


On 15 Mar 2017 10:35, "R Smith" <> wrote:

> On 2017/03/14 2:54 PM, PICCORO McKAY Lenz wrote:
>> an important feature in a DB its the column field that gives to developers
>> metadata info INDEPENDENT of the tecnologies used, due by this way with a
>> simple text editor in generated script developer can read and use minimal
>> info for understanding structure ...
>> its a minimal feature need in a database, for many developers that make
>> GOOD documentation!
> I know this is not implementing the feature, but may I suggest some way to
> achieve the same.
> What we do (typically), since SQLite supports C-type comment blocks /* ...
> */, is to add comment lines to the schema and they are preserved correctly.
> For example:
> CREATE TABLE "test" (
>   "ID" INTEGER /* Here we add column comments */,
>   "Name" TEXT /* Note the comma is AFTER the comment */,
>   "EMail" TEXT COLLATE NOCASE /* Username (Unique Key) */,
> CONSTRAINT UI_test_EMail UNIQUE (EMail) /* This is an Index comment */
> ) /* and this is a Table comment, before the final semi-colon  */;
> This will be kept exactly as-is in the SQL field of the schema table
> (main.sqlite_master) and is easy to parse out later, or use a standard tool
> that already does it. This is an example of the auto-generated schema
> documentation from sqlitespeed ( using exactly this
> method of commenting. It includes the actual SQL blocks so it's easy to see
> how the commenting gets parsed:
> Go directly to the "Cities" table to see the idea also applied to FK
> constraint and Index items.
> I know this is not strictly what you need, but I understand the
> frustration of not having comments, so this is how we solved it, maybe
> something similar will work for you.
> Cheers,
> Ryan
> _______________________________________________
> sqlite-users mailing list
sqlite-users mailing list

Reply via email to