On Thu, Jun 8, 2017 at 12:15 PM, Jens Alfke wrote:
> SQLite is primarily an _embedded_ database library. In that use case,
> comments on the schema properly belong in the program that creates the
> database, next to the sqlite3_exec("CREATE TABLE…”) calls.
>
> I realize that when SQLite is being
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 sch
"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 comme
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 i
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 Chrzanow
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 co
On Jun 7, 2017, at 10:37 AM, Stephen Chrzanowski wrote:
>
> You can't be 100% certain that GitHub is going to
> be online tomorrow
As well, we have plenty of history showing that we can’t trust the long-term
availability or trustworthiness of third party hosting services. Major
examples are S
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
GitHu
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 fo
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-0
Not exactly.
You're free to extend it yourself and submit it for consideration though. I
think that you'll just need to adopt the same standards as are in use
within the usual enhancements channels.
Regards.
Brian P Curley
On Wed, Jun 7, 2017 at 12:09 PM, PICCORO McKAY Lenz
wrote:
> 2017-06
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 cl
On 6/7/17, PICCORO McKAY Lenz wrote:
> the github issue tracker are more easy to send.. register can made with any
> openid service.. no a complicated email out/of/time system.. its the 21
> century men
I would suggest, then, that you grab a copy of the SQLite source code,
put it on github, and s
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 the
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 reque
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
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.
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:
> >
>
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 ot
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 b
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" th
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 def
On 2017/03/15 5:36 PM, Richard Hipp wrote:
On 3/15/17, Bob Friesenhahn wrote:
On Wed, 15 Mar 2017, R Smith wrote:
CREATE TABLE "test" (
"ID" INTEGER /* Here we add column comments */,
"Name" TEXT /* Note the comma is AFTER the comment */,
"EMail" TEXT COLLATE NOCASE /* Username (Unique K
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 ha
On 3/15/17, Bob Friesenhahn wrote:
> On Wed, 15 Mar 2017, R Smith wrote:
>>
>> CREATE TABLE "test" (
>> "ID" INTEGER /* Here we add column comments */,
>> "Name" TEXT /* Note the comma is AFTER the comment */,
>> "EMail" TEXT COLLATE NOCASE /* Username (Unique Key) */,
>> CONSTRAINT UI_test_EMa
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 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,
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 f
On 15 Mar 2017, at 2:45pm, Bart Smissaert wrote:
> Maybe it is simpler (no parsing needed) to have an extra table with a
> unique column holding tablename_fieldname
> and a second column holding the comment for that field.
It’s common to see a four column table, with the columns being
entityTy
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
On 15 Mar 2017, at 2:30pm, PICCORO McKAY Lenz wrote:
> so can introduce a feature that converts all parts that have COMMENT '(\*)'
> to /* COMMENT */ and stored? in the master part of the Database?
It is unlikely that this will happen in SQLite3. What Brian is telling you is
that /you/ can re
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...
s
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
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
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
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 ...
Ther
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 tecno
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 s
Can't you add it to the field name?
For example for a field holding date of birth: DOB_INT or DOB_TXT.
RBS
On Tue, Mar 14, 2017 at 12:54 PM, PICCORO McKAY Lenz wrote:
> an important feature in a DB its the column field that gives to developers
> metadata info INDEPENDENT of the tecnologies us
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 databa
40 matches
Mail list logo
