feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

PICCORO McKAY Lenz
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!


Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

Bart Smissaert
Can't you add it to the field name?
For example for a field holding date of birth: DOB_INT or DOB_TXT.

RBS



On Tue, Mar 14, 2017 at 12:54 PM, PICCORO McKAY Lenz <[hidden email]
> 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!
>
>
> Lenz McKAY Gerardo (PICCORO)
> http://qgqlochekone.blogspot.com
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

Gert Van Assche-3
In reply to this post by PICCORO McKAY Lenz
I usually add a table with comments to other tables and fields for this.
That does the trick for me.
Is there another way to do it?

2017-03-14 13:54 GMT+01:00 PICCORO McKAY Lenz <[hidden email]>:

> 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!
>
>
> Lenz McKAY Gerardo (PICCORO)
> http://qgqlochekone.blogspot.com
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>



--
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Gert Van Assche
Skype: gertva -- Mobile: +32 498 84 44 75
datamundi.be -- fairtradetranslation.com -- delifteducation.be
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

R Smith
In reply to this post by PICCORO McKAY Lenz

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 (www.sqlc.rifin.co.za) using
exactly this method of commenting. It includes the actual SQL blocks so
it's easy to see how the commenting gets parsed:
http://www.sqlc.rifin.co.za/SchemaDocExample1.html

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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

Clemens Ladisch
In reply to this post by PICCORO McKAY Lenz
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 ...

There is no widely accepted standard for comments in SQL, except /* actual
comments */, and neither is there one for metadata, except as actual data
in your own metadata table(s).  Adding some non-standard mechanism would
not allow anything that isn't already possible.


Regards,
Clemens
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

Chris Locke-3
Just add a 'comments' table.  Seems a lot of extra work and 'extra tools'
needed to read the comments, which could potentially be missed.
Add a 'comments' table with a 'comment' field which you can even add dates,
usernames, etc, to.

Thanks,
Chris

On Wed, Mar 15, 2017 at 11:12 AM, Clemens Ladisch <[hidden email]>
wrote:

> 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 ...
>
> There is no widely accepted standard for comments in SQL, except /* actual
> comments */, and neither is there one for metadata, except as actual data
> in your own metadata table(s).  Adding some non-standard mechanism would
> not allow anything that isn't already possible.
>
>
> Regards,
> Clemens
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

Brian Curley
The sqlite_master table will always preserve any comments embedded between
the "CREATE" and ";" keywords for a given table definition. Is this not
sufficient?

You can parse the sql for a table's record to retrieve comments, in
whichever format you're using. I know that SQLite supports both single line
("-- ..") and multi-line ("/* .. */") forms of comments, so your parsing
might need to handle either/both according to your style book.

Regards.

Brian P Curley



On Wed, Mar 15, 2017 at 7:40 AM, Chris Locke <[hidden email]>
wrote:

> Just add a 'comments' table.  Seems a lot of extra work and 'extra tools'
> needed to read the comments, which could potentially be missed.
> Add a 'comments' table with a 'comment' field which you can even add dates,
> usernames, etc, to.
>
> Thanks,
> Chris
>
> On Wed, Mar 15, 2017 at 11:12 AM, Clemens Ladisch <[hidden email]>
> wrote:
>
> > 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 ...
> >
> > There is no widely accepted standard for comments in SQL, except /*
> actual
> > comments */, and neither is there one for metadata, except as actual data
> > in your own metadata table(s).  Adding some non-standard mechanism would
> > not allow anything that isn't already possible.
> >
> >
> > Regards,
> > Clemens
> > _______________________________________________
> > sqlite-users mailing list
> > [hidden email]
> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> >
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

Simon Slavin-3

On 15 Mar 2017, at 1:27pm, Brian Curley <[hidden email]> wrote:

> The sqlite_master table will always preserve any comments embedded between
> the "CREATE" and ";" keywords for a given table definition. Is this not
> sufficient?

I always found that interesting.  I would have thought that the parser for SQLite would strip out those comments before the stage at which the CREATE commands were stored.  However, it’s not true.

Simon.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

PICCORO McKAY Lenz
hey their'e WIDELY USED keyword and practice in all mayor DBMS

so can introduce a feature that converts all parts that have COMMENT '(\*)'
to /* COMMENT */ and stored? in the master part of the Database?

and NOTED THAT no many users comes here due the complicated behavior of
report an issue...

so then some bugs have been her for years due that..

this feature are widelly need for many developers, (make a search in
google) but due the asking for feature request are so complicated.. same
for bug reports

sorry guys but must be better in this behavior

Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

2017-03-15 10:27 GMT-04:00 Simon Slavin <[hidden email]>:

>
> On 15 Mar 2017, at 1:27pm, Brian Curley <[hidden email]> wrote:
>
> > The sqlite_master table will always preserve any comments embedded
> between
> > the "CREATE" and ";" keywords for a given table definition. Is this not
> > sufficient?
>
> I always found that interesting.  I would have thought that the parser for
> SQLite would strip out those comments before the stage at which the CREATE
> commands were stored.  However, it’s not true.
>
> Simon.
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

Simon Slavin-3

On 15 Mar 2017, at 2:30pm, PICCORO McKAY Lenz <[hidden email]> wrote:

> so can introduce a feature that converts all parts that have COMMENT '(\*)'
> to /* COMMENT */ and stored? in the master part of the Database?

It is unlikely that this will happen in SQLite3.  What Brian is telling you is that /you/ can recall the command made to create the table, and parse comments in it yourself.  To get a list of all tables in the database, use the following SELECT command:

SELECT name,sql FROM sqlite_master
    WHERE type='table'
    ORDER BY name;

To get the CREATE command for a particular table use

SELECT sql FROM sqlite_master
    WHERE name='MyTable';

Simon.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

Bart Smissaert
In reply to this post by R Smith
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.

RBS



On 15 Mar 2017 10:35, "R Smith" <[hidden email]> 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 (www.sqlc.rifin.co.za) using exactly this
> method of commenting. It includes the actual SQL blocks so it's easy to see
> how the commenting gets parsed:
> http://www.sqlc.rifin.co.za/SchemaDocExample1.html
>
> 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
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

Simon Slavin-3

On 15 Mar 2017, at 2:45pm, Bart Smissaert <[hidden email]> wrote:

> 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.

It’s common to see a four column table, with the columns being

entityType
theTable
theName
theComment

(I picked column names that suit me.  I don’t know of a standard.  Use of 'the' is to make sure you aren’t using reserved words as entity names.)

This allows you to comment things like indexes and triggers as well as columns.

Simon.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

Richard Hipp-3
On 3/15/17, Simon Slavin <[hidden email]> wrote:
>
> It’s common to see a four column table, with the columns being
>
> entityType
> theTable
> theName
> theComment
>

This approach has the advantage of being portable across *all* SQL
database engines, whereas the COMMENT ON command is (as far as I could
discern from Google) only available on Oracle and PostgreSQL.   This
approach also makes the comments easy to introspect from applications,
and update using general-purpose query tools.
--
D. Richard Hipp
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

PICCORO McKAY Lenz
the idea its that many tools generated (due portability and compability)
sql script with a optional keyword COMMENT on each column definition..

this its xxtremely usefull for selft container documentation for many
console users and rapid development

so manual comment using C-like cannot do that, if i have a large set of
DB's with minimal of 20 tables, its widelly tedious manage comments in that
way that some here sugest me.. and later joint the db files for work?

.. and stop of recomend me stupid guindows tools like sqlitespeed, does not
sqlite are Public Domain thanks god and aliens, but i hate all the
protected breaking-portability like all the guindows progs, the main reason
that's why we have problems porting apps

Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

2017-03-15 11:05 GMT-04:00 Richard Hipp <[hidden email]>:

> On 3/15/17, Simon Slavin <[hidden email]> wrote:
> >
> > It’s common to see a four column table, with the columns being
> >
> > entityType
> > theTable
> > theName
> > theComment
> >
>
> This approach has the advantage of being portable across *all* SQL
> database engines, whereas the COMMENT ON command is (as far as I could
> discern from Google) only available on Oracle and PostgreSQL.   This
> approach also makes the comments easy to introspect from applications,
> and update using general-purpose query tools.
> --
> D. Richard Hipp
> [hidden email]
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

Bob Friesenhahn
In reply to this post by R Smith
On Wed, 15 Mar 2017, R Smith wrote:

>
> 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

Are these comments loaded into memory used by each program which
connects to the database?  If so, more resources are consumed.

Bob
--
Bob Friesenhahn
[hidden email], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

Richard Hipp-3
On 3/15/17, Bob Friesenhahn <[hidden email]> wrote:

> On Wed, 15 Mar 2017, R Smith wrote:
>>
>> 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
>
> Are these comments loaded into memory used by each program which
> connects to the database?  If so, more resources are consumed.

The comments are loaded into memory temporarily while the CREATE TABLE
statement is being parsed when the connection is first opened, but
they are not held in memory long-term.  The text of the CREATE TABLE
is freed as soon as the schema parse completes.  So there is no extra
long-term memory usage.
--
D. Richard Hipp
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

R Smith
In reply to this post by PICCORO McKAY Lenz


On 2017/03/15 5:15 PM, PICCORO McKAY Lenz wrote:

> so manual comment using C-like cannot do that, if i have a large set of
> DB's with minimal of 20 tables, its widelly tedious manage comments in that
> way that some here sugest me.. and later joint the db files for work?

Well, the advantage of having comments in DB tables (as some suggested)
is also that you have the entire SQL language functions available to
manipulate the comments - which you don't have when they are treated
like Meta-data.
That said, only some DBs include comment in-schema specifiers, like
Postgres and MySQL as Richard pointed out, in MSSQL you have to add a
comment by a whole other mechanism. There is no standard for it. And
even where these DBs do keep comments, they are all in large SCHEMA
tables kept with per-column entries and the like. SQLite doesn't keep a
per-column schema table, but you may.


> .. and stop of recomend me stupid guindows tools like sqlitespeed, does not
> sqlite are Public Domain thanks god and aliens, but i hate all the
> protected breaking-portability like all the guindows progs, the main reason
> that's why we have problems porting apps

Easy sailor... There is no need for you use that specific "stupid
guindows tool", it's simply that the tool had solved the comment problem
by parsing the schema, and you could do something like it.

Also, neither God nor any Aliens had anything to do with the development
of SQLite. I suppose if they did we would have had this before the
atomic bomb - and how much you "hate" anything is of no concern. If you
can provide a good reasoned approach to solving the problem, people will
listen, and even now the devs will probably be able to say:

Your request has been noted, Thank you for the suggestion.

Have a great day,
Ryan


_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

R Smith
In reply to this post by Richard Hipp-3
On 2017/03/15 5:36 PM, Richard Hipp wrote:

> On 3/15/17, Bob Friesenhahn <[hidden email]> wrote:
>> On Wed, 15 Mar 2017, R Smith wrote:
>>> 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
>> Are these comments loaded into memory used by each program which
>> connects to the database?  If so, more resources are consumed.
> The comments are loaded into memory temporarily while the CREATE TABLE
> statement is being parsed when the connection is first opened, but
> they are not held in memory long-term.  The text of the CREATE TABLE
> is freed as soon as the schema parse completes.  So there is no extra
> long-term memory usage.

I wonder, sqlite Devs, if a pragma or other adaption (such as the
current pragma table_info()) or such could produce the same exact data
but with an added field called "Comment" that simply gives the parsed
comment from after each column definition (if any) like the above table
example. This would probably be a very small adaptation, be completely
backwards compatible, doesn't break any standard (since there isn't any)
and answer the need expressed by this thread and others before it.


_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

Dominique Devienne
On Wed, Mar 15, 2017 at 4:57 PM, R Smith <[hidden email]> wrote:

> I wonder, sqlite Devs, if a pragma or other adaption (such as the current
> pragma table_info()) or such could produce the same exact data but with an
> added field called "Comment" that simply gives the parsed comment from
> after each column definition (if any) like the above table example. This
> would probably be a very small adaptation, be completely backwards
> compatible, doesn't break any standard (since there isn't any) and answer
> the need expressed by this thread and others before it.


That's one way to solve it, in a mostly BC (Backward Compatible) way.
(modulo the output from table_info() changing, which could be opt-in to
make it fully BC).

But given the HIDDEN key in vtables [1] "precedent", could also be an
explicit COMMENT 'some text' in the create table DDL itself, w/o resorting
to "significant" comments. --DD

[1] https://sqlite.org/vtab.html#hidden_columns_in_virtual_tables
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

Simon Slavin-3

On 15 Mar 2017, at 4:09pm, Dominique Devienne <[hidden email]> wrote:

> On Wed, Mar 15, 2017 at 4:57 PM, R Smith <[hidden email]> wrote:
>
>> I wonder, sqlite Devs, if a pragma or other adaption (such as the current
>> pragma table_info()) or such could produce the same exact data but with an
>> added field called "Comment" that simply gives the parsed comment from
>> after each column definition (if any) like the above table example. This
>> would probably be a very small adaptation, be completely backwards
>> compatible, doesn't break any standard (since there isn't any) and answer
>> the need expressed by this thread and others before it.
>
> That's one way to solve it, in a mostly BC (Backward Compatible) way.
> (modulo the output from table_info() changing, which could be opt-in to
> make it fully BC).

Problem is, it requires parsing the CREATE command looking for comments in a certain format.  Notoriously difficult, considering that they can contain CR, LF, tab, and unforeseen Unicode characters.

I’m utterly against anything that tries to read C-style comments.  Comments are comments.  Computers are meant to ignore them to the point that they don’t even know they exist.

On the other hand, if we establish a standard for storing comments in database tables — which would require a consistent table name, column names, and values — it might take too much extra time to show those comments as an extra column in the response to PRAGMA tale_info() and similar PRAGMAs.  But I think it’s overkill.  Anyone who would want that would know how to retrieve the information.

Simon.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
12
Loading...