"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 <slav...@bigfraud.org> wrote: > > > On 6 Jun 2017, at 2:17pm, PICCORO McKAY Lenz <mckaygerh...@gmail.com> > 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
