Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!
On Thu, Jun 8, 2017 at 12:15 PM, Jens Alfkewrote: > 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!!
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!!
"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 Slavinwrote: > > > 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!!
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!!
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!!
On 6 Jun 2017, at 2:17pm, PICCORO McKAY Lenzwrote: > 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!!
On Jun 7, 2017, at 10:37 AM, Stephen Chrzanowskiwrote: > > 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!!
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 Lenzwrote: > 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!!
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 Lenzwrote: > 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!!
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!!
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 Lenzwrote: > 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!!
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!!
On 6/7/17, PICCORO McKAY Lenzwrote: > 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!!
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!!
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 Lenzwrote: > 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!!
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!!
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 Lenzwrote: > 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!!
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!!
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!!
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!!
On 15 Mar 2017, at 4:09pm, Dominique Deviennewrote: > 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!!
On Wed, Mar 15, 2017 at 4:57 PM, R Smithwrote: > 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!!
On 2017/03/15 5:36 PM, Richard Hipp wrote: On 3/15/17, Bob Friesenhahnwrote: 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!!
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!!
On 3/15/17, Bob Friesenhahnwrote: > 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!!
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!!
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!!
On 15 Mar 2017, at 2:45pm, Bart Smissaertwrote: > 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!!
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!!
On 15 Mar 2017, at 2:30pm, PICCORO McKAY Lenzwrote: > 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!!
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!!
On 15 Mar 2017, at 1:27pm, Brian Curleywrote: > 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!!
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 Lockewrote: > 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!!
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 Ladischwrote: > 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!!
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!!
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!!
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!!
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 Lenzwrote: > 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