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 // <http://plasmasturm.org/>


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

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

[Aristotle Pagaltzis]

* 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 // 

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

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

[Aristotle Pagaltzis]

* Zbigniew Baniewski <[EMAIL PROTECTED]> [2008-01-09 12:15]:
> Keep your flamewar just to yourself, will you?

I’m sorry if that’s all you saw in my mail.

Regards,
-- 
Aristotle Pagaltzis // 

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

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

[Aristotle Pagaltzis]

* Zbigniew Baniewski <[EMAIL PROTECTED]> [2008-01-07 03:35]:
> I think, that it sometimes could be useful as secondary
> protection: a feature (perhaps another "pragma"?), which will
> cause stripping the spaces from beginning and end of every
> inserted string.

http://sqlite.org/lang_createtrigger.html


* Zbigniew Baniewski <[EMAIL PROTECTED]> [2008-01-07 17:55]:
> Yes: and from the perspective of the makers, perhaps this
> doesn't have to look that bad: it's just using some C-function
> to strip every string-value directly before insertion... I
> don't expect, that this can cause a mess.

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.

http://blog.plover.com/prog/featurism.html

Special-purpose features that do not help with anything else have
no place in a library that is going to be used by hundreds of
thousands of people.

Some more on that by Mark Jason Dominus:

It’s all right to be so short-sighted when you’re designing
software for yourself, but when you design a language that
will be used by thousands or millions of people, you have to
have more economy. Every feature has a cost in implementation
and maintenance and documentation and education, so the
language designer has to make every feature count. If a
feature isn’t widely useful to many people for many different
kinds of tasks, it has negative value. In the limit, to
accomplish all the things that people want from a language,
unless most of your features are powerful and flexible, you
have to include so very many of them that the language
becomes an impossible morass. (Of course, there is another
theory which states that this has already happened.)

This came as no surprise to me. I maintain the Memoize
module, which is fairly popular. People would frequently send
me mail asking me to add a certain feature, such as timed
expiration of cached data. I would reply that I didn’t want
to do that, because it would slow down the module for
everyone, and it would not help the next time I got a similar
but slightly different request, such as a request for data
that expires when it has been used a fixed number of times.
The response was invariably along the lines of “But what
would anyone want to do that for?” And then the following
week I would get mail from someone else asking for expiration
of data after it had been used a fixed number of times, and I
would say that I didn’t want to put this in because it
wouldn’t help people with the problem of timed expiration AND
THE RESPONSE WOULD BE EXACTLY THE SAME. A module author must
be good at foreseeing this sort of thing, and good at finding
the best compromise solution for everyone’s problems, not
just the butt-pimple of the week. A language designer must be
even better at doing this, because many, many people will be
stuck with the language for years.

SQLite’s design doesn’t quite constitute a full-blown language,
but it’s more demanding than a plain library.

Regards,
-- 
Aristotle Pagaltzis // 

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

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

[Igor Tandetnik]

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