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
|

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

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

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

PICCORO McKAY Lenz
In reply to this post by Simon Slavin-3
2017-03-15 12:24 GMT-04:00 Simon Slavin <[hidden email]>:

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

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

PICCORO McKAY Lenz
In reply to this post by Simon Slavin-3
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 <[hidden email]>:

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

Re: 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 <[hidden email]> 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 <[hidden email]>:
>
>>
>> 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
>>
> _______________________________________________
> 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
|

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

> 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 <[hidden email]> 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 <[hidden email]>:
>>
>>>
>>> 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
>>>
>> _______________________________________________
>> 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
|

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

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

> 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 <[hidden email]
> >
> 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 <[hidden email]>:
> > > 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 <[hidden email]>
> > 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 <[hidden email]>:
> > >>
> > >>>
> > >>> 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
> > >>>
> > >> _______________________________________________
> > >> 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
> >
> _______________________________________________
> 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
|

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

Richard Hipp-3
On 6/7/17, PICCORO McKAY Lenz <[hidden email]> 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
[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
|

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

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

Re: 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 <[hidden email]>
wrote:

> 2017-06-07 9:59 GMT-04:00 Richard Hipp <[hidden email]>:
>
> > 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
> > [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
|

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

> 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 <
> [hidden email]>
> wrote:
>
> > 2017-06-07 9:59 GMT-04:00 Richard Hipp <[hidden email]>:
> >
> > > 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
> > > [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
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]>
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 <[hidden email]>:
>
> > 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 <
> > [hidden email]>
> > wrote:
> >
> > > 2017-06-07 9:59 GMT-04:00 Richard Hipp <[hidden email]>:
> > >
> > > > 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
> > > > [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
> >
> _______________________________________________
> 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
|

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

Stephen Chrzanowski
In reply to this post by PICCORO McKAY Lenz
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 <[hidden email]>
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 <[hidden email]>:
>
> > 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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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.

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

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

Simon Slavin-3
In reply to this post by PICCORO McKAY Lenz


On 6 Jun 2017, at 2:17pm, PICCORO McKAY Lenz <[hidden email]> 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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

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

PICCORO McKAY Lenz
In reply to this post by Stephen Chrzanowski
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 <[hidden email]>:

> 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 <
> [hidden email]>
> 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 <[hidden email]>:
> >
> > > 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
> [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
|

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

PICCORO McKAY Lenz
In reply to this post by Simon Slavin-3
2017-06-07 13:57 GMT-04:00 Simon Slavin <[hidden email]>:

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

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

Don V Nielsen
In reply to this post by Simon Slavin-3
"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 <[hidden email]> wrote:

>
>
> On 6 Jun 2017, at 2:17pm, PICCORO McKAY Lenz <[hidden email]>
> 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
> [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
|

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

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

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