RE: [sqlite] Re: "always-trim" - feature suggestion

[Fred Williams]

> -Original Message-
> From: Aristotle Pagaltzis [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, January 09, 2008 1:27 PM
> To: sqlite-users@sqlite.org
> Subject: [sqlite] Re: "always-trim" - feature suggestion
> 
> 
> * Zbigniew Baniewski <[EMAIL PROTECTED]> [2008-01-09 18:15]:
> > On Wed, Jan 09, 2008 at 11:25:01AM -0500, Rob Sciuk wrote:
> > > and adding bloat will not contribute to its future success.
> > 
> > Of course, any feature, which *you* aren't especially fond of,
> > you can describe as "bloat". Even the most useful feature
> > (which is useful FOR ME) - can be "bloat" for you. And vice
> > versa. No, I'm not using *all*available* features of SQLite.
> > Are they "bloat"? Answer yourself.
> 
> Yes, actually, almost all requested and many implemented features
> are by definition bloat. Linus Torvalds once said that his most
> important job as the maintainer of the kernel is to say no to
> most suggested additions. I’m sure Dr. Hipp could give a list of
> things he would remove from SQLite if backward compatibility was
> not a concern.
> 
> Regards,
> -- 
> Aristotle Pagaltzis // 


I think one central issue related to SQLite does cause the most friction in the 
community. It is the never ending quest for "more features."  I feel the 
majority of users did not select SQLite for "the features" as SQLite by design 
avoids features to remain true to its history, culture, and place in the 
universe.  I did not select SQLite for the features.  I selected SQL Server, 
Oracle, and a couple of others for the features.  I selected SQLite for the 
lack of features.

I think none of the generated friction is intentional or divisive in nature.  
Some of us do a better job of communicating than others no matter what the base 
reason.  "Technical Computer" types have also had the historical if not 
accurate legacy of, "not playing well with others."  Since we aint in Marketing 
or Advertising I suspect a certain amount of truth to that perception.  And we 
usually have the unpopular duty of telling others what the Marketing and 
Advertising crowd has failed to mention, after they have left the building and 
the ink on the contract is not even dry.

Given all that, I have been guilty of being less than a perfect communicator on 
many occasions.  But I have found the participants on this list on a whole to 
be one of the better groups of technical types I have been associated with.  
Unfortunately there are instances where, normally a very passionate individual 
or idea is presented and is perceived as was unintended.

I pulled that "failure to communicate" trick recently with VB coder references. 
 Fortunately that thread died a well deserved death earlier than this one.  
But, it did little to change my opinion of BASIC as a computer "language." :-)  

Fred




-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] Re: "always-trim" - feature suggestion

[Zbigniew Baniewski]

On Wed, Jan 09, 2008 at 08:27:13PM +0100, Aristotle Pagaltzis wrote:

> Yes, actually, almost all requested and many implemented features
> are by definition bloat.

It depends on definition, I guess... ;)
-- 
pozdrawiam / regards

Zbigniew Baniewski

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] Re: "always-trim" - feature suggestion

[Zbigniew Baniewski]

On Wed, Jan 09, 2008 at 12:01:05PM +0100, Aristotle Pagaltzis wrote:

> No, it doesn???t. And the next tiny feature like yours will not
> cause a mess either. And the next one after that won???t cause a
> mess either. Now keep addding tiny cannot-cause-a-mess features
> for two years and the result *will* be a massive mess.

Keep your flamewar just to yourself, will you? Thank you.
-- 
pozdrawiam / regards

Zbigniew Baniewski

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] Re: "always-trim" - feature suggestion

[Zbigniew Baniewski]

On Mon, Jan 07, 2008 at 03:29:21PM -0800, Darren Duncan wrote:

> The job of a DB isn't just storage of your data, but also to ensure 
> that the data it stores is always conformant to the types and 
> restrictions or business rules that you tell it applies to the data, 
> so that the data can be trusted.
> 
> It makes a lot of sense for a DBMS to be smart and to do a lot of the 
> data-centric work itself.

Yes, _I_ agree, that it's not just "job of storage". Just for storage
purposes a plain file (or .dbf) can be quite enough in most cases.

> However, that doesn't mean that the DBMS 
> has to have a large laundry-list of built-in functions, but more that 
> it provides the means for users to define the types and business 
> rules that it wants the DBMS to enforce for data, and routines for 
> data processing tasks. [..]
> I don't see that auto-strip is a good candidate for that list ... not 
> enough of a case for that being generally useful, or too many cases 
> for why it would be a mis-feature whose use should not get the 
> encouragement from it being built-in.

OK, I understand. It was just a proposal, anyway.
-- 
pozdrawiam / regards

Zbigniew Baniewski

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] Re: "always-trim" - feature suggestion

[Darren Duncan]

At 9:14 PM +0100 1/7/08, Zbigniew Baniewski wrote:

On Mon, Jan 07, 2008 at 10:41:35AM -0800, Ken wrote:

 In the spirit of the conversation the OP wants the DB to strip out white
 space. I contend that this is the applications responsibility either as
 DRH suggested by using proper sql expressions. Or by using a trigger. Or
 better yet by implementing inside his application if possible adding code
 to strip white space.


I'm not sure, whether did you notice, that I wrote about the same - and my
feature suggestion was: "because it's so common operation, repeated again
and again - perhaps the database server/engine could do it"?


 Triggers are another route, but I recommend letting the DB do its job of
 storage. [..]


Forgive me for being contrary: you just wrote, that most of core functions
listed on  http://www.sqlite.org/lang_expr.html  seems to be useless. They
aren't related to "DB's job of storage" at all, anyway.


The job of a DB isn't just storage of your data, but also to ensure 
that the data it stores is always conformant to the types and 
restrictions or business rules that you tell it applies to the data, 
so that the data can be trusted.


It makes a lot of sense for a DBMS to be smart and to do a lot of the 
data-centric work itself.  However, that doesn't mean that the DBMS 
has to have a large laundry-list of built-in functions, but more that 
it provides the means for users to define the types and business 
rules that it wants the DBMS to enforce for data, and routines for 
data processing tasks.


So the DBMS itself can be fairly 'lite', and users get the advantage 
of having work done in the DBMS while writing that work themselves. 
I believe that SQLite already fulfills this mandate to a large 
degree, and if it needs more features, it is to provide better 
support for users to define the their own database constructs, not 
pre-define every possible thing that a user may want to do.  We don't 
want something designed like PHP.


For your needs, the best thing SQLite can do is provide support for 
you to define constraint checks that the strings it stores don't have 
leading/trailing spaces, and provide support for you to write stored 
procedure wrappers over your insert/update/etc that strip out 
leading/trailing spaces.  If this stuff ought to be a pragma, then 
SQLite should support users defining their own pragmas, rather than 
it having this strip-strings one built-in.


I will also clarify that it is useful for SQLite to have some 
built-in functionality beyond letting users write their own, but I 
don't see that auto-strip is a good candidate for that list ... not 
enough of a case for that being generally useful, or too many cases 
for why it would be a mis-feature whose use should not get the 
encouragement from it being built-in.


-- Darren Duncan

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] Re: "always-trim" - feature suggestion

[Zbigniew Baniewski]

On Mon, Jan 07, 2008 at 10:41:35AM -0800, Ken wrote:

> In the spirit of the conversation the OP wants the DB to strip out white
> space. I contend that this is the applications responsibility either as
> DRH suggested by using proper sql expressions. Or by using a trigger. Or
> better yet by implementing inside his application if possible adding code
> to strip white space.

I'm not sure, whether did you notice, that I wrote about the same - and my
feature suggestion was: "because it's so common operation, repeated again
and again - perhaps the database server/engine could do it"?

> Triggers are another route, but I recommend letting the DB do its job of
> storage. [..]

Forgive me for being contrary: you just wrote, that most of core functions
listed on  http://www.sqlite.org/lang_expr.html  seems to be useless. They
aren't related to "DB's job of storage" at all, anyway.
-- 
pozdrawiam / regards

Zbigniew Baniewski

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] Re: "always-trim" - feature suggestion

[Ken]

Igor,

Thanks for the correction on that, probably my wording "I don't think" in my 
mind it meant I'm not sure... Lol, but thats another storry. Check constraints 
are a feature I've not used in sqlite, so hence "I don't think", my mistake and 
my applogies.

In the spirit of the conversation the OP wants the DB to strip out white space. 
I contend that this is the applications responsibility either  as DRH suggested 
by using proper sql expressions. Or by using a trigger. Or better yet by 
implementing inside his application if possible adding code to strip white 
space. 

Triggers are another route, but I recommend letting the DB do its job of 
storage. Don't add the overhead of adding data scrubbing as well. Do the 
scrubbing at the application side where it belongs.

Regards,
Ken


Igor Tandetnik <[EMAIL PROTECTED]> wrote: Ken  wrote:
> Some commecial products have "check constraints" that allow you to
> enable a check on a column that can be stored procedural code. That
> could also be another way of keeping "non-trimmed" data out.  
> 
> I don't think sqlite supports column level check contstraints.

Does too.

create table test(txt CHECK(txt = trim(txt)));
insert into test(txt) values(' a '); -- constraint failed

Igor Tandetnik

-
To unsubscribe, send email to [EMAIL PROTECTED]
-