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

[John McKown]

On Thu, Jun 8, 2017 at 12:15 PM, Jens Alfke  wrote:

> SQLite is primarily an _embedded_ database library. In that use case,
> comments on the schema properly belong in the program that creates the
> database, next to the sqlite3_exec("CREATE TABLE…”) calls.
>
> I realize that when SQLite is being used as a command-line DBM tool,
> having comments in the schema itself would be useful. But this is a
> minority use case.
>
> As someone who uses SQLite in mobile and IOT app development, I really do
> not want features in the core — increasing its size, complexity and
> potential for bugs — that are not of use for embedded databases.
>
> —Jens
>

​I agree with you. Sometimes it seems to me that people are basically
saying "Why isn't SQLite identical to Oracle?" (or PostgreSQL).​


-- 
Prof: So the American government went to IBM to come up with a data
encryption standard and they came up with ...

Student: EBCDIC!

Maranatha! <><
John McKown
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

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

[Jens Alfke]

SQLite is primarily an _embedded_ database library. In that use case, comments 
on the schema properly belong in the program that creates the database, next to 
the sqlite3_exec("CREATE TABLE…”) calls.

I realize that when SQLite is being used as a command-line DBM tool, having 
comments in the schema itself would be useful. But this is a minority use case.

As someone who uses SQLite in mobile and IOT app development, I really do not 
want features in the core — increasing its size, complexity and potential for 
bugs — that are not of use for embedded databases.

—Jens
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

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

[Don V Nielsen]

"CREATE TABLE meta_comments"

Simon, isn't your approach the most logical solution rather than
incorporating a comment column into the master? Once incorporated, wouldn't
you be opening yourself up to a litany of "Not the way we work", "We need
feature x to be useful", "What if we want a null comment?" and user stuff
like that? Your framework gives something to build off of, can be adapted
at will, and is not part of the core.

Personally, I would find it *helpful* to have a comment column, but it is
certainly not critical to the operation of the database. It's not a must
have feature for this db.

Just my two cents, or less

On Wed, Jun 7, 2017 at 12:57 PM, Simon Slavin  wrote:

>
>
> On 6 Jun 2017, at 2:17pm, PICCORO McKAY Lenz 
> wrote:
>
> > how its the status of this work?
>
> The work of parsing comments in the CREATE TABLE command ?  I don’t think
> anyone else thinks this is worth working on.  Discussion in this list has
> come up with many reasons why it’s a poor way to store comments, including
>
> * Difficulty of parsing text which may have CR, LT, tab, comma, etc..
> * Impossible to update the comments without DROPping and reCREATEing the
> table because SQLite implements only a few ALTER TABLE commands.
> * Documentation restricted to one language.
>
> Here’s a simple version of the best system I ever came up with from
> working in multi-programmer projects, where clear comments were important
> to letting one developer know what another intended.  Comments for a
> database can be stored in the following table in that database:
>
> CREATE TABLE meta_comments (
> entityType TEXT COLLATE NOCASE NOT NULL,
> theTable TEXT COLLATE NOCASE NOT NULL,
> theName TEXT COLLATE NOCASE NOT NULL,
> theComment TEXT COLLATE NOCASE NOT NULL,
> PRIMARY KEY (entityType, theTable, theName));
>
> Values for "entityType" can be ’schema’,'table','index','trigger','view',
> and anything else you want to document.
>
> If you need multilanguage documentation (required for some countries which
> work to protect a language) add a "language TEXT COLLATE NOCASE NOT NULL"
> field and include it in the primary key.  Ih one use of an early version of
> this we also used a field called "theVersion" to document changes in each
> entity, though I don’t know how sensible that is for most uses.  We also
> used to use a table like this to store commands, though if I was designing
> that system from scratch now I’d use a different table.
>
> I came up with the above structure myself, warrant that it is not
> encumbered by any intellectual property, and dedicate it to the public
> domain.  Anyone can use it for anything they want.
>
> Simon.
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

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

[PICCORO McKAY Lenz]

2017-06-07 13:57 GMT-04:00 Simon Slavin :

> The work of parsing comments in the CREATE TABLE command ?  I don’t think
> anyone else thinks this is worth working on.  Discussion in this list has
> come up with many reasons why it’s a poor way to store comments, including
>
i'm aware of them.. but its a limited support:


> * Difficulty of parsing text which may have CR, LT, tab, comma, etc..
>
use standard way, only LF no comma and TAB allowed.. POSIX always


> * Impossible to update the comments without DROPping and reCREATEing the
> table because SQLite implements only a few ALTER TABLE commands.
>
umm that's enough for limited support!


> * Documentation restricted to one language.
>
i dont understant the meaning of, why multilang comments...?


>
> Here’s a simple version of the best system I ever came up with from
> working in multi-programmer projects, where clear comments were important
> to letting one developer know what another intended.  Comments for a
> database can be stored in the following table in that database:
>
> CREATE TABLE meta_comments (
> entityType TEXT COLLATE NOCASE NOT NULL,
> theTable TEXT COLLATE NOCASE NOT NULL,
> theName TEXT COLLATE NOCASE NOT NULL,
> theComment TEXT COLLATE NOCASE NOT NULL,
> PRIMARY KEY (entityType, theTable, theName));
>
> Values for "entityType" can be ’schema’,'table','index','trigger','view',
> and anything else you want to document.
>
that its a good limited aproach! limit the comments to only 12 chars to not
overhead the db size


>
> If you need multilanguage documentation (required for some countries which
> work to protect a language) add a "language TEXT COLLATE NOCASE NOT NULL"
> field and include it in the primary key.  Ih one use of an early version of
> this we also used a field called "theVersion" to document changes in each
> entity, though I don’t know how sensible that is for most uses.  We also
> used to use a table like this to store commands, though if I was designing
> that system from scratch now I’d use a different table.
>

the mayor problem its when sqlite join two files/databases to share the
comments with the other

>
> I came up with the above structure myself, warrant that it is not
> encumbered by any intellectual property, and dedicate it to the public
> domain.  Anyone can use it for anything they want.
>
that its good...enought


>
> Simon.
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

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

[PICCORO McKAY Lenz]

ipost github as example.. there a sourceforge git capabilities over large
years.. also  You can't be 100% certain that Ricahd resources is going to
be online tomorrow.. sf.net, github, gitlab and googlecode are still only
voer many years... and all of them works with openid...

for Stephen Chrzanowski  and Simon Slavin thans for their responses,
i-ll (due the stric wrokflow of old-behaviour of maillist software) will
answer in another mail to conserver the threath workflow (that its not
happened in a real issue tracker)

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

2017-06-07 12:37 GMT-04:00 Stephen Chrzanowski :

> Why should Richard and other devs rely on something other than their own
> work and source control?  You can't be 100% certain that GitHub is going to
> be online tomorrow, which means that a scramble to push code to another
> site is going to happen.  You can't be certain that whatever comes after
> GitHub and becomes the default place to go for public code repository.
>
> What Richard has put in place is entirely under his control, his management
> style, his methodologies, and his implementation.  21st century or not,
> he's not a lemming and doesn't have to jump on the next bandwagon.
>
> As for the comment about registration, you need to register to get onto
> GitHub as well.  So outside a mail client of my choice, I now have to worry
> about a web browser and trust that the remote site is going to be
> available, what the provider is going to do with my information.
>
>
>
> On Wed, Jun 7, 2017 at 12:17 PM, PICCORO McKAY Lenz <
> mckaygerh...@gmail.com>
> wrote:
>
> > hello brian, what standars? reading deeply the sqlite site i not see the
> > @issue buton@
> >
> > only see that all contact way must be in the mail list... its a 21
> century
> > and ID urls its the standar way of integration...
> >
> > Lenz McKAY Gerardo (PICCORO)
> > http://qgqlochekone.blogspot.com
> >
> > 2017-06-07 12:12 GMT-04:00 Brian Curley :
> >
> > > Not exactly.
> > >
> > > You're free to extend it yourself and submit it for consideration
> > though. I
> > > think that you'll just need to adopt the same standards as are in use
> > > within the usual enhancements channels.
> > >
> > > Regards.
> > >
> > > Brian P Curley
> > >
> > >
> >
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

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

[Simon Slavin]

On 6 Jun 2017, at 2:17pm, PICCORO McKAY Lenz  wrote:

> how its the status of this work?

The work of parsing comments in the CREATE TABLE command ?  I don’t think 
anyone else thinks this is worth working on.  Discussion in this list has come 
up with many reasons why it’s a poor way to store comments, including

* Difficulty of parsing text which may have CR, LT, tab, comma, etc..
* Impossible to update the comments without DROPping and reCREATEing the table 
because SQLite implements only a few ALTER TABLE commands.
* Documentation restricted to one language.

Here’s a simple version of the best system I ever came up with from working in 
multi-programmer projects, where clear comments were important to letting one 
developer know what another intended.  Comments for a database can be stored in 
the following table in that database:

CREATE TABLE meta_comments (
entityType TEXT COLLATE NOCASE NOT NULL,
theTable TEXT COLLATE NOCASE NOT NULL,
theName TEXT COLLATE NOCASE NOT NULL,
theComment TEXT COLLATE NOCASE NOT NULL,
PRIMARY KEY (entityType, theTable, theName));

Values for "entityType" can be ’schema’,'table','index','trigger','view', and 
anything else you want to document.

If you need multilanguage documentation (required for some countries which work 
to protect a language) add a "language TEXT COLLATE NOCASE NOT NULL" field and 
include it in the primary key.  Ih one use of an early version of this we also 
used a field called "theVersion" to document changes in each entity, though I 
don’t know how sensible that is for most uses.  We also used to use a table 
like this to store commands, though if I was designing that system from scratch 
now I’d use a different table.

I came up with the above structure myself, warrant that it is not encumbered by 
any intellectual property, and dedicate it to the public domain.  Anyone can 
use it for anything they want.

Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

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

[Warren Young]

On Jun 7, 2017, at 10:37 AM, Stephen Chrzanowski  wrote:
> 
> You can't be 100% certain that GitHub is going to
> be online tomorrow

As well, we have plenty of history showing that we can’t trust the long-term 
availability or trustworthiness of third party hosting services.  Major 
examples are Sourceforge and Google Code in this section of the software 
universe, and we have lots of examples in other areas if those two aren’t 
enough.

> 21st century or not,
> he's not a lemming and doesn't have to jump on the next bandwagon.

The Fossil project was started in 2006, so it’s a 21st century solution, by 
definition. :)

> As for the comment about registration, you need to register to get onto
> GitHub as well.

Wlll, that’s not really the OP’s point, now is it?

The real distinction is that GitHub doesn’t care about your actual identity, 
just that you can be proven to exist somewhere on the Internet in a uniquely 
identifiable fashion.  According to GitHub, there are two “Warren Young” 
entities who both happen to live in my house. :)  One of them more often logs 
in from that house and the other most often logs in from $dayjob’s computers, 
but they’re the same person, and GitHub doesn’t know it.

Fossil, on the other hand, is for projects where all of the developers are 
expected to know each other at some personal level before they join; maybe not 
by face, but certainly by reputation.

There is no “Fork me on Fossil”, on purpose.  Semi-anonymous forks hurt project 
cohesiveness.

In theory, GitHub allows one of the forks to emerge as dominant, pulling in 
changes from more other forks than the others, but more often I see bunches of 
semi-private forks on GitHub, with no hope that the forked versions will ever 
merge changes back upstream.  They might as well be private checkouts with 
local modifications for all the value this sort of forking provides.

In absence of a strong central project, you end up with multiple versions all 
holding the same weight, according to GitHub, with no way for the end user to 
select among them.  I know I’ve personally Googled some project and been 
mislead to someone’s private GitHub mirror of it, simply because GitHub has so 
much Google juice that it often outranks the actual source of the project.  If 
there are multiple mirrors in GitHub, you won’t even know that they’re all 
non-canonical.

The “Fork me on GitHub” model is also fundamentally mismatched with respect to 
projects like Fossil and SQLite where formal license grants (Fossil) or license 
disclaimers (SQLite) are required before changes can be merged into the master 
project.  Repository login grants in such a project are actually just a 
formality gated by the real gatekeeping mechanism, that being the signed 
contributor agreement.

Bottom line, Fossil is perfectly suited to SQLite’s needs, as it should be, 
given that it was created to serve it.

Fossil is also great for other projects of its sort: small to medium sized 
project managed by a small, cohesive group.

Git-style distributed development is better for non-cohesive projects, or for 
those so large that Git’s complexity-bought advantages start to pay off.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

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

[Stephen Chrzanowski]

Why should Richard and other devs rely on something other than their own
work and source control?  You can't be 100% certain that GitHub is going to
be online tomorrow, which means that a scramble to push code to another
site is going to happen.  You can't be certain that whatever comes after
GitHub and becomes the default place to go for public code repository.

What Richard has put in place is entirely under his control, his management
style, his methodologies, and his implementation.  21st century or not,
he's not a lemming and doesn't have to jump on the next bandwagon.

As for the comment about registration, you need to register to get onto
GitHub as well.  So outside a mail client of my choice, I now have to worry
about a web browser and trust that the remote site is going to be
available, what the provider is going to do with my information.



On Wed, Jun 7, 2017 at 12:17 PM, PICCORO McKAY Lenz 
wrote:

> hello brian, what standars? reading deeply the sqlite site i not see the
> @issue buton@
>
> only see that all contact way must be in the mail list... its a 21 century
> and ID urls its the standar way of integration...
>
> Lenz McKAY Gerardo (PICCORO)
> http://qgqlochekone.blogspot.com
>
> 2017-06-07 12:12 GMT-04:00 Brian Curley :
>
> > Not exactly.
> >
> > You're free to extend it yourself and submit it for consideration
> though. I
> > think that you'll just need to adopt the same standards as are in use
> > within the usual enhancements channels.
> >
> > Regards.
> >
> > Brian P Curley
> >
> >
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

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

[Brian Curley]

They're using Fossil as the repository. You'll want to confirm the steps
required, but the main access point is as follow (I believe):

   https://www.sqlite.org/src/login

The main concern is that the functionality that you seek might not scale to
the broader user base. You can always extend it for yourself, and provide a
proof of concept back to the main trunk that may choose to adopt it too.

Otherwise, I think that there were a number of alternative approaches
outlined earlier in the thread. Some of these, such as assigning a
dedicated local database table in addition to sqlite_master, might actually
suffice for your need without impairing users who rely on the program in
the wild.

Regards.

Brian P Curley

On Wed, Jun 7, 2017 at 12:17 PM, PICCORO McKAY Lenz 
wrote:

> hello brian, what standars? reading deeply the sqlite site i not see the
> @issue buton@
>
> only see that all contact way must be in the mail list... its a 21 century
> and ID urls its the standar way of integration...
>
> Lenz McKAY Gerardo (PICCORO)
> http://qgqlochekone.blogspot.com
>
> 2017-06-07 12:12 GMT-04:00 Brian Curley :
>
> > Not exactly.
> >
> > You're free to extend it yourself and submit it for consideration
> though. I
> > think that you'll just need to adopt the same standards as are in use
> > within the usual enhancements channels.
> >
> > Regards.
> >
> > Brian P Curley
> >
> >
> >
> > On Wed, Jun 7, 2017 at 12:09 PM, PICCORO McKAY Lenz <
> > mckaygerh...@gmail.com>
> > wrote:
> >
> > > 2017-06-07 9:59 GMT-04:00 Richard Hipp :
> > >
> > > > I would suggest, then, that you grab a copy of the SQLite source
> code,
> > > > put it on github, and start your own fork.  You can then add whatever
> > > > new SQL commands you want.
> > > >
> > > > At this point, your chances of getting us to do your work for you are
> > > > very close to zero.
> > > >
> > > that's not was the topic.. but in any case its a response of the style:
> > > "works for me, doit yourselft"
> > >
> > >
> > > >
> > > > --
> > > > D. Richard Hipp
> > > > d...@sqlite.org
> > > >
> > > ___
> > > sqlite-users mailing list
> > > sqlite-users@mailinglists.sqlite.org
> > > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> > >
> > ___
> > sqlite-users mailing list
> > sqlite-users@mailinglists.sqlite.org
> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> >
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

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

[PICCORO McKAY Lenz]

hello brian, what standars? reading deeply the sqlite site i not see the
@issue buton@

only see that all contact way must be in the mail list... its a 21 century
and ID urls its the standar way of integration...

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

2017-06-07 12:12 GMT-04:00 Brian Curley :

> Not exactly.
>
> You're free to extend it yourself and submit it for consideration though. I
> think that you'll just need to adopt the same standards as are in use
> within the usual enhancements channels.
>
> Regards.
>
> Brian P Curley
>
>
>
> On Wed, Jun 7, 2017 at 12:09 PM, PICCORO McKAY Lenz <
> mckaygerh...@gmail.com>
> wrote:
>
> > 2017-06-07 9:59 GMT-04:00 Richard Hipp :
> >
> > > I would suggest, then, that you grab a copy of the SQLite source code,
> > > put it on github, and start your own fork.  You can then add whatever
> > > new SQL commands you want.
> > >
> > > At this point, your chances of getting us to do your work for you are
> > > very close to zero.
> > >
> > that's not was the topic.. but in any case its a response of the style:
> > "works for me, doit yourselft"
> >
> >
> > >
> > > --
> > > D. Richard Hipp
> > > d...@sqlite.org
> > >
> > ___
> > sqlite-users mailing list
> > sqlite-users@mailinglists.sqlite.org
> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> >
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

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

[Brian Curley]

Not exactly.

You're free to extend it yourself and submit it for consideration though. I
think that you'll just need to adopt the same standards as are in use
within the usual enhancements channels.

Regards.

Brian P Curley



On Wed, Jun 7, 2017 at 12:09 PM, PICCORO McKAY Lenz 
wrote:

> 2017-06-07 9:59 GMT-04:00 Richard Hipp :
>
> > I would suggest, then, that you grab a copy of the SQLite source code,
> > put it on github, and start your own fork.  You can then add whatever
> > new SQL commands you want.
> >
> > At this point, your chances of getting us to do your work for you are
> > very close to zero.
> >
> that's not was the topic.. but in any case its a response of the style:
> "works for me, doit yourselft"
>
>
> >
> > --
> > D. Richard Hipp
> > d...@sqlite.org
> >
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

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

[PICCORO McKAY Lenz]

2017-06-07 9:59 GMT-04:00 Richard Hipp :

> I would suggest, then, that you grab a copy of the SQLite source code,
> put it on github, and start your own fork.  You can then add whatever
> new SQL commands you want.
>
> At this point, your chances of getting us to do your work for you are
> very close to zero.
>
that's not was the topic.. but in any case its a response of the style:
"works for me, doit yourselft"


>
> --
> D. Richard Hipp
> d...@sqlite.org
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

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

[Richard Hipp]

On 6/7/17, PICCORO McKAY Lenz  wrote:
> the github issue tracker are more easy to send.. register can made with any
> openid service.. no a complicated email out/of/time system.. its the 21
> century men

I would suggest, then, that you grab a copy of the SQLite source code,
put it on github, and start your own fork.  You can then add whatever
new SQL commands you want.

At this point, your chances of getting us to do your work for you are
very close to zero.

-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

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

[PICCORO McKAY Lenz]

the github issue tracker are more easy to send.. register can made with any
openid service.. no a complicated email out/of/time system.. its the 21
century men

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

2017-06-07 9:24 GMT-04:00 Stephen Chrzanowski :

> What other way would there be?  Just anonymous "Fix it, add this, do it
> now!" kind of messages?  If you don't register, then anyone can start
> spamming the hell outta the message board.
>
> On Wed, Jun 7, 2017 at 9:15 AM, PICCORO McKAY Lenz  >
> wrote:
>
> > the problem its that for making some noise or request users must
> > register, send email, waith response aproval.. too complicated
> > processs.. that's the reason
> > Lenz McKAY Gerardo (PICCORO)
> > http://qgqlochekone.blogspot.com
> >
> >
> > 2017-06-07 2:16 GMT-04:00 Daniel Kamil Kozar :
> > > Patches are still welcome, I guess. I haven't seen anybody claiming
> > > that this would be done in any way.
> > >
> > > On 6 June 2017 at 15:17, PICCORO McKAY Lenz 
> > wrote:
> > >> how its the status of this work?
> > >>
> > >> a limited implementation will be good!
> > >>
> > >> Lenz McKAY Gerardo (PICCORO)
> > >> http://qgqlochekone.blogspot.com
> > >>
> > >> 2017-03-15 12:24 GMT-04:00 Simon Slavin :
> > >>
> > >>>
> > >>> On 15 Mar 2017, at 4:09pm, Dominique Devienne 
> > wrote:
> > >>>
> > >>> > On Wed, Mar 15, 2017 at 4:57 PM, R Smith 
> 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
> > >>> sqlite-users@mailinglists.sqlite.org
> > >>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> > >>>
> > >> ___
> > >> sqlite-users mailing list
> > >> sqlite-users@mailinglists.sqlite.org
> > >> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> > > ___
> > > sqlite-users mailing list
> > > sqlite-users@mailinglists.sqlite.org
> > > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> > ___
> > sqlite-users mailing list
> > sqlite-users@mailinglists.sqlite.org
> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> >
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

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

[Stephen Chrzanowski]

What other way would there be?  Just anonymous "Fix it, add this, do it
now!" kind of messages?  If you don't register, then anyone can start
spamming the hell outta the message board.

On Wed, Jun 7, 2017 at 9:15 AM, PICCORO McKAY Lenz 
wrote:

> the problem its that for making some noise or request users must
> register, send email, waith response aproval.. too complicated
> processs.. that's the reason
> Lenz McKAY Gerardo (PICCORO)
> http://qgqlochekone.blogspot.com
>
>
> 2017-06-07 2:16 GMT-04:00 Daniel Kamil Kozar :
> > Patches are still welcome, I guess. I haven't seen anybody claiming
> > that this would be done in any way.
> >
> > On 6 June 2017 at 15:17, PICCORO McKAY Lenz 
> wrote:
> >> how its the status of this work?
> >>
> >> a limited implementation will be good!
> >>
> >> Lenz McKAY Gerardo (PICCORO)
> >> http://qgqlochekone.blogspot.com
> >>
> >> 2017-03-15 12:24 GMT-04:00 Simon Slavin :
> >>
> >>>
> >>> On 15 Mar 2017, at 4:09pm, Dominique Devienne 
> wrote:
> >>>
> >>> > On Wed, Mar 15, 2017 at 4:57 PM, R Smith  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
> >>> sqlite-users@mailinglists.sqlite.org
> >>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> >>>
> >> ___
> >> sqlite-users mailing list
> >> sqlite-users@mailinglists.sqlite.org
> >> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> > ___
> > sqlite-users mailing list
> > sqlite-users@mailinglists.sqlite.org
> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

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

[PICCORO McKAY Lenz]

the problem its that for making some noise or request users must
register, send email, waith response aproval.. too complicated
processs.. that's the reason
Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com


2017-06-07 2:16 GMT-04:00 Daniel Kamil Kozar :
> Patches are still welcome, I guess. I haven't seen anybody claiming
> that this would be done in any way.
>
> On 6 June 2017 at 15:17, PICCORO McKAY Lenz  wrote:
>> how its the status of this work?
>>
>> a limited implementation will be good!
>>
>> Lenz McKAY Gerardo (PICCORO)
>> http://qgqlochekone.blogspot.com
>>
>> 2017-03-15 12:24 GMT-04:00 Simon Slavin :
>>
>>>
>>> On 15 Mar 2017, at 4:09pm, Dominique Devienne  wrote:
>>>
>>> > On Wed, Mar 15, 2017 at 4:57 PM, R Smith  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
>>> sqlite-users@mailinglists.sqlite.org
>>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>>
>> ___
>> sqlite-users mailing list
>> sqlite-users@mailinglists.sqlite.org
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

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

[Daniel Kamil Kozar]

Patches are still welcome, I guess. I haven't seen anybody claiming
that this would be done in any way.

On 6 June 2017 at 15:17, PICCORO McKAY Lenz  wrote:
> how its the status of this work?
>
> a limited implementation will be good!
>
> Lenz McKAY Gerardo (PICCORO)
> http://qgqlochekone.blogspot.com
>
> 2017-03-15 12:24 GMT-04:00 Simon Slavin :
>
>>
>> On 15 Mar 2017, at 4:09pm, Dominique Devienne  wrote:
>>
>> > On Wed, Mar 15, 2017 at 4:57 PM, R Smith  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
>> sqlite-users@mailinglists.sqlite.org
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

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

[PICCORO McKAY Lenz]

how its the status of this work?

a limited implementation will be good!

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

2017-03-15 12:24 GMT-04:00 Simon Slavin :

>
> On 15 Mar 2017, at 4:09pm, Dominique Devienne  wrote:
>
> > On Wed, Mar 15, 2017 at 4:57 PM, R Smith  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
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

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

[PICCORO McKAY Lenz]

2017-03-15 12:24 GMT-04:00 Simon Slavin :

> 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.
>
well limit the comment to 255 chars and if any other non valid were found,
ignore it! like tabs, newlines, etc.. truncate


> 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.
>
and if db's configure it to by default do not show this "extra" information?


>
> Simon.
> _default do not show this "extra" _
> _
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

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

[PICCORO McKAY Lenz]

2017-03-15 11:49 GMT-04:00 R Smith :

> 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

that's one firts reason that rely on the second, comment can handle (with
the DBMS) the build in necesary documentation selft conained inside on the
DB, that its helfull for all, (very)


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

make this in master db can make obvously incompatible and can made grow the
size depends of the comment size and amount of the tables and columns..
but, taking in considerations that today nobody of us take care about that
(machines are so powerfully right?) so makin a extra schema its enought


> Your request has been noted, Thank you for the suggestion.
>
many thanks! really appreciated!

this request was made prevously by another person, see archives.. many many
years ago
also was widelly requested in internet network by many years, but due the
very complicated behavior of the request / bugtraking system for sqlite..
no much was received here


> in MSSQL you have to add a comment by a whole other mechanism.

??? in my job we have complete SQL SERVER 2014 SP1 and performance need a
complete dell r600 and usage of the compelte 1T of RAM need extra
licences.. and more extra and extra "integrations" and then u mention that:

> 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.
>
we use (again) MS-like soft due "recomended", these king of
"recomendations" was the reason of the problem.. we have to paid, mid-usage
of a software we cannot migrate easy now! and we cannot use "complete"
today without a "grow-deep" dependence of the MS ...
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

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

[Simon Slavin]

On 15 Mar 2017, at 4:09pm, Dominique Devienne  wrote:

> On Wed, Mar 15, 2017 at 4:57 PM, R Smith  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
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 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  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
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

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

[R Smith]

On 2017/03/15 5:36 PM, Richard Hipp wrote:

On 3/15/17, Bob Friesenhahn  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
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

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

[R Smith]

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
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

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

[Richard Hipp]

On 3/15/17, Bob Friesenhahn  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
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

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

[Bob Friesenhahn]

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
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 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 :

> On 3/15/17, Simon Slavin  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
> d...@sqlite.org
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

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

[Simon Slavin]

On 15 Mar 2017, at 2:45pm, Bart Smissaert  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
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

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

[Bart Smissaert]

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"  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
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

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

[Simon Slavin]

On 15 Mar 2017, at 2:30pm, PICCORO McKAY Lenz  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
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 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 :

>
> On 15 Mar 2017, at 1:27pm, Brian Curley  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
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

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

[Simon Slavin]

On 15 Mar 2017, at 1:27pm, Brian Curley  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
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 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 
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 
> 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
> > sqlite-users@mailinglists.sqlite.org
> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> >
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

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

[Chris Locke]

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 
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
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

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

[Clemens Ladisch]

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
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

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

[Gert Van Assche]

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 :

> 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
> sqlite-users@mailinglists.sqlite.org
> 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
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

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

[R Smith]

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
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 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  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
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users