Re: [sqlite] "always-trim" - feature suggestion
Some of the correspondents seem to have lost track of the meaning of "Open Source". They have the source code and can build their own version which trims, slashes or even burns. They certainly do not have to inflict their particular needs or preferences on the whole user community. I am sure that a prime reason for the success of Sqlite is that it's creator maintains discipline and saves it from becoming a bloated mess. Rob Sciuk wrote: On Wed, 9 Jan 2008, Zbigniew Baniewski wrote: On Wed, Jan 09, 2008 at 12:51:16PM +, [EMAIL PROTECTED] wrote: Why not have a possibility to make it default behaviour of the SQL-engine itself, just by using one "pragma"? 1. It'll make my code shorter. But it makes the SQLite core code larger. Why should the the SQLite core be enlarged for the convenience of a single user. It's rather hard to say, if really just "single". SQLite, as I understood, has many users; just three of them were "against", until this time. Who knows, which of the existing features are used by how many users? Yesterday one of them wrote, that (if I properly understood) he appreciates nothing more, than "job of storage". 2. It'll make my life easier. ;) But it makes my life harder. [..] Probably a bit - but it was your own choice of such way of life, anyway. ;) You know, I believe that an "embedded" SQL has a philosophy which is inherently minimalist. Your request specifically goes against the philosophy of what SQLite was designed to be. DRH is working hard to protect an ideal which has appealed to millions, and continues to do so, and adding bloat will not contribute to its future success. There is nothing to top you from *FORKING* the SQLite project into a kitchen sink version of MySQL, PostGresql, Firebird or any of a number of existing full featured databases, and then *YOU* can be the one to determine what features belong in *YOUR* database managment system, and take on the work of implementing every idea which comes along ... Perhaps SQL_Obese? - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] "always-trim" - feature suggestion
On Wed, Jan 09, 2008 at 07:16:27PM +, [EMAIL PROTECTED] wrote: > Puneet also speaks for me on this matter. I'm glad, dr. Hipp, you haven't found my answer as offensive or abusive - of course, as I wrote, it was just a proposal, an idea - not any "demanding". But to know your opinion about this - I had to express my own first. It's all. Thanks for all your efforts, which, of course, are greatly appreciated - what I would do on this list otherwise? -- pozdrawiam / regards Zbigniew Baniewski - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] "Can't we all just get along?" [Was: RE: [sqlite] "always-trim" - feature suggestion]]
On Wed, Jan 09, 2008 at 11:12:42AM -0800, James Dennett wrote: > To take an example (and I apologize for it being from your message, but > that's a convenient place): when you write "I ended the discussion > *yesterday* already", it's easy for me to take that as being rude > because it implies that you have the power to unilaterally terminate a > discussion on this list. Now, I think that you really meant that you > stated yesterday that *you* did not need any further discussion, and I > don't really believe that you intended to tell others that they are not > permitted to continue the discussion if they wish to do so. However, if > I were of a mind to look for "rudeness", I could find it even where none > was intended. Sorry, perhaps I should write: "from my side..." - or something like this. I meant just: "the answer was `no', and I accepted this - and there was no need to `beat that horse' any further", as someone politely wrote. > Our goals here are the same -- we want SQLite to continue to be a fine > database within its niche, and to improve. It's natural that there are > disagreements on what constitutes "improvement", and even that there > will be tensions as the forces behind those disagreements are resolved. > Let's not waste time debating perceived insults on the list? Thanks, James and Puneet; it wasn't my intention to offend anybody, perhaps partially my (not so well, still working on this) english is to blame, but I'm not native speaker - consider this, reading any of my posts -- pozdrawiam / regards Zbigniew Baniewski - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] "always-trim" - feature suggestion
"P Kishor" <[EMAIL PROTECTED]> wrote: > fwiw, Zbigniew, I did not consider you rude or argumentative, but yes, > this thread would have been "trimmed" a lot earlier after pretty much > the very first "request for implementation." > > I hope you won't be put off by any perceived "hostility." No one wants > to be that way. Your comments, contributions and suggestions, even > help to other newbies, will always be welcome and will enrich the > SQLite community. Please stay active on the list and don't mind any > minor friction here and there. > > I, of course, speak for myself, and not for other companies. > Puneet also speaks for me on this matter. -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] -
[sqlite] "Can't we all just get along?" [Was: RE: [sqlite] "always-trim" - feature suggestion]]
> -Original Message- > From: Zbigniew Baniewski [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 09, 2008 10:57 AM > To: sqlite-users@sqlite.org > Subject: Re: [sqlite] "always-trim" - feature suggestion > > On Wed, Jan 09, 2008 at 07:15:52PM +0100, Kees Nuyt wrote: > > > It's a culture thing. In Eastern Europe this is the normal way > > of reasoning, and isn't considered rude (my girlfriend is > > Latvian from Russian parents, so I have some experience with > > this kind of culture shock). > > I'm afraid, I don't understand. Am I expected here to agree with everyone, > because I'll be seen as "rude" otherwise? No, not at all: in fact, differences of opinion are common on this list, and generally don't cause problems because most list participants have similar notions of culturally "polite" ways to resolve them. > That's too bad - but it's not my > way to change my mind under pressure. The best technical results don't come from such pressure, I'd certainly agree. > Everyone here can have his/her own opinion - and so can I. And my opinion > can differ from the opinion of the others' (and vice versa). > > Ending the thread (I hope), I want to repeat: I wrote *yesterday*: "OK, no > problem". Everyone can check out this lists archive. The devs - especially > "the Highest One" - answered "no", and it's enough for me. But my opinion > about the proposed feature stays. So what? It's mine. Perhaps really - > after > ending my current work - I'll write that patch on my own. Fred, Ken and > all > the others' (even that mentioned "poor ***") can have different opinions, > of > their own. I didn't deny it - as (almost) all the others are denying my > right to have my own opinion. > > I can't understand all that people tryin' to start a flamewar here *after* > I ended the discussion *yesterday* already. Are they bored, and looking > for > some doubtful "fun"? But why exactly here? No, they're not trying to start a flamewar -- they're reacting to what they honestly perceive as _you_ flaming. But your flaming was, in turn, your response to a post from Aristotle Pagaltzis which I'm sure you honestly considered flaming, though by the standards of most list participants Aristotle was doing exactly what you defend: politely expressing his disagreement with your opinion, and explaining why he disagreed. I don't think there is any bad intention behind any of the posts here. It's best (for both sides) not to assume bad faith, and to understand that when we communicate in e-mail from around the world, sometimes we'll do it in different ways. To take an example (and I apologize for it being from your message, but that's a convenient place): when you write "I ended the discussion *yesterday* already", it's easy for me to take that as being rude because it implies that you have the power to unilaterally terminate a discussion on this list. Now, I think that you really meant that you stated yesterday that *you* did not need any further discussion, and I don't really believe that you intended to tell others that they are not permitted to continue the discussion if they wish to do so. However, if I were of a mind to look for "rudeness", I could find it even where none was intended. Our goals here are the same -- we want SQLite to continue to be a fine database within its niche, and to improve. It's natural that there are disagreements on what constitutes "improvement", and even that there will be tensions as the forces behind those disagreements are resolved. Let's not waste time debating perceived insults on the list? Regards, James - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] "always-trim" - feature suggestion
fwiw, Zbigniew, I did not consider you rude or argumentative, but yes, this thread would have been "trimmed" a lot earlier after pretty much the very first "request for implementation." I hope you won't be put off by any perceived "hostility." No one wants to be that way. Your comments, contributions and suggestions, even help to other newbies, will always be welcome and will enrich the SQLite community. Please stay active on the list and don't mind any minor friction here and there. I, of course, speak for myself, and not for other companies. pozdrawiam. Puneet. On 1/9/08, Zbigniew Baniewski <[EMAIL PROTECTED]> wrote: > On Wed, Jan 09, 2008 at 07:15:52PM +0100, Kees Nuyt wrote: > > > It's a culture thing. In Eastern Europe this is the normal way > > of reasoning, and isn't considered rude (my girlfriend is > > Latvian from Russian parents, so I have some experience with > > this kind of culture shock). > > I'm afraid, I don't understand. Am I expected here to agree with everyone, > because I'll be seen as "rude" otherwise? That's too bad - but it's not my > way to change my mind under pressure. > > Everyone here can have his/her own opinion - and so can I. And my opinion > can differ from the opinion of the others' (and vice versa). > > Ending the thread (I hope), I want to repeat: I wrote *yesterday*: "OK, no > problem". Everyone can check out this lists archive. The devs - especially > "the Highest One" - answered "no", and it's enough for me. But my opinion > about the proposed feature stays. So what? It's mine. Perhaps really - after > ending my current work - I'll write that patch on my own. Fred, Ken and all > the others' (even that mentioned "poor ***") can have different opinions, of > their own. I didn't deny it - as (almost) all the others are denying my > right to have my own opinion. > > I can't understand all that people tryin' to start a flamewar here *after* > I ended the discussion *yesterday* already. Are they bored, and looking for > some doubtful "fun"? But why exactly here? > -- > pozdrawiam / regards > > Zbigniew Baniewski > > - > To unsubscribe, send email to [EMAIL PROTECTED] > - > > -- Puneet Kishor http://punkish.eidesis.org/ Nelson Institute for Environmental Studies http://www.nelson.wisc.edu/ Open Source Geospatial Foundation (OSGeo) http://www.osgeo.org/ Summer 2007 S Policy Fellow, The National Academies http://www.nas.edu/ - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] "always-trim" - feature suggestion
On Wed, Jan 09, 2008 at 07:15:52PM +0100, Kees Nuyt wrote: > It's a culture thing. In Eastern Europe this is the normal way > of reasoning, and isn't considered rude (my girlfriend is > Latvian from Russian parents, so I have some experience with > this kind of culture shock). I'm afraid, I don't understand. Am I expected here to agree with everyone, because I'll be seen as "rude" otherwise? That's too bad - but it's not my way to change my mind under pressure. Everyone here can have his/her own opinion - and so can I. And my opinion can differ from the opinion of the others' (and vice versa). Ending the thread (I hope), I want to repeat: I wrote *yesterday*: "OK, no problem". Everyone can check out this lists archive. The devs - especially "the Highest One" - answered "no", and it's enough for me. But my opinion about the proposed feature stays. So what? It's mine. Perhaps really - after ending my current work - I'll write that patch on my own. Fred, Ken and all the others' (even that mentioned "poor ***") can have different opinions, of their own. I didn't deny it - as (almost) all the others are denying my right to have my own opinion. I can't understand all that people tryin' to start a flamewar here *after* I ended the discussion *yesterday* already. Are they bored, and looking for some doubtful "fun"? But why exactly here? -- pozdrawiam / regards Zbigniew Baniewski - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] "always-trim" - feature suggestion
On Wed, Jan 09, 2008 at 12:04:54PM -0600, Fred Williams wrote: > range beginning with MySQL and ending with Oracle. I do not beat a dead > horse trying to get the entire SQLite world and Dr. Hipp in particular > to "see it MY way." Give it up and look for a more feature rich DB and > leave us poor dumb Bas--rds using SQLite alone! I gave it up yesterday already. What's your point, exactly? -- pozdrawiam / regards Zbigniew Baniewski - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] "always-trim" - feature suggestion
On Wed, 9 Jan 2008 08:57:18 -0800 (PST), Ken <[EMAIL PROTECTED]> wrote: > I think your being argumentative, > disrespectful and just plain rude. I don't think Zbigniew does that on purpose. It's a culture thing. In Eastern Europe this is the normal way of reasoning, and isn't considered rude (my girlfriend is Latvian from Russian parents, so I have some experience with this kind of culture shock). We can't expect all posters here to conform to Western European or USAn habits. -- ( Kees Nuyt ) c[_] - To unsubscribe, send email to [EMAIL PROTECTED] -
RE: [sqlite] "always-trim" - feature suggestion
> -Original Message- > From: Zbigniew Baniewski [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 09, 2008 11:08 AM > To: sqlite-users@sqlite.org > Subject: Re: [sqlite] "always-trim" - feature suggestion > > > On Wed, Jan 09, 2008 at 11:25:01AM -0500, Rob Sciuk wrote: > > > You know, I believe that an "embedded" SQL has a philosophy > which is > > inherently minimalist. > > ...yes, I know. > > > Your request specifically goes against the > > philosophy of what SQLite was designed to be. DRH is > working hard to > > protect an ideal which has appealed to millions, and > continues to do so, > > Of course, I appreciate work of dr. Hipp > > > 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. > > > I'm not quite sure, what is the point in continuing this thread, when > *yesterday* already I responded to the denial sent by Darren > Duncan, that > it's OK, and I can understand, that the devs didn't share my > point of view. > If it's going to convince me, that I don't need what I need - it's > pointless, because I know my own needs much better. Otherwise > I've got no > idea, where should it going to, when I already wrote "OK, no problem". > -- > pozdrawiam / regards > > Zbigniew Baniewski I have been very effectively using SQLite for quite some time now, and have watched with great reservation as it has "swelled" over that time. My use of the product is to provide very simple SQL enabled backend storage for any application not to be implemented in an "enterprise" environment. My applications do all the business rule, data prettying, validation, and any other "feature" not provided by SQLite. This allows me to tailor my application (Mostly using "Cut and Paste" like efforts.) to fit on most any platform environment from PDA to File Server. That is the reason I use SQLite, and for that reason only. If I need a greater feature set than SQLite provides, I have a multitude of database engines at my disposal with greater feature sets and price range beginning with MySQL and ending with Oracle. I do not beat a dead horse trying to get the entire SQLite world and Dr. Hipp in particular to "see it MY way." Give it up and look for a more feature rich DB and leave us poor dumb Bas--rds using SQLite alone! Fred - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] "always-trim" - feature suggestion
On Wed, Jan 09, 2008 at 08:57:18AM -0800, Ken wrote: > After reading your response to DRH, I think your being argumentative, > disrespectful and just plain rude. Thanks, I love you too. -- pozdrawiam / regards Zbigniew Baniewski - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] "always-trim" - feature suggestion
On Wed, Jan 09, 2008 at 11:25:01AM -0500, Rob Sciuk wrote: > You know, I believe that an "embedded" SQL has a philosophy which is > inherently minimalist. ...yes, I know. > Your request specifically goes against the > philosophy of what SQLite was designed to be. DRH is working hard to > protect an ideal which has appealed to millions, and continues to do so, Of course, I appreciate work of dr. Hipp > 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. I'm not quite sure, what is the point in continuing this thread, when *yesterday* already I responded to the denial sent by Darren Duncan, that it's OK, and I can understand, that the devs didn't share my point of view. If it's going to convince me, that I don't need what I need - it's pointless, because I know my own needs much better. Otherwise I've got no idea, where should it going to, when I already wrote "OK, no problem". -- pozdrawiam / regards Zbigniew Baniewski - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] "always-trim" - feature suggestion
It's rather hard to say, if really just "single". SQLite, as I understood, has many users; just three of them were "against", until this time. Who knows, which of the existing features are used by how many users? Yesterday one of them wrote, that (if I properly understood) he appreciates nothing more, than "job of storage". I need many other features of sqlite, its just i see the DB's #1 job as storage. After reading your response to DRH, I think your being argumentative, disrespectful and just plain rude. Thats probably not going to get you far. Since SQLITE source code is freely available, you can always create a patch to the code for the pragma your interested in. And maintain your own version. Ken
Re: [sqlite] "always-trim" - feature suggestion
On Wed, 9 Jan 2008 14:33:40 +0100, Zbigniew Baniewski <[EMAIL PROTECTED]> wrote: >On Wed, Jan 09, 2008 at 12:51:16PM +, [EMAIL PROTECTED] wrote: > >> > Why not have a possibility to make it default >> > behaviour of the SQL-engine itself, just by >> > using one "pragma"? >> > >> > 1. It'll make my code shorter. >> >> But it makes the SQLite core code larger. Why should the the >> SQLite core be enlarged for the convenience of a single user. > >It's rather hard to say, if really just "single". >SQLite, as I understood, has many users; just three >of them were "against", until this time. Most people are not really "me2" type of persons, so they don't speak out. But if you insist: although it seems a nice to have feature, I'm against an auto_trim PRAGMA. In my opinion drh's reasoning is valid. I, for example, would be able to come up with several features comparable to the one you propose, such as auto_uppercase, auto_lowercase, or auto_fill_asterisk (for lawyers), you name it. As the source of SQLite is in the public domain it won't be too difficult to build your own sqlite3_bind_trimmedtext(). I usually delegate the data-validation and -massaging to the application level. -- ( Kees Nuyt ) c[_] - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] "always-trim" - feature suggestion
On Wed, 9 Jan 2008, Zbigniew Baniewski wrote: On Wed, Jan 09, 2008 at 12:51:16PM +, [EMAIL PROTECTED] wrote: Why not have a possibility to make it default behaviour of the SQL-engine itself, just by using one "pragma"? 1. It'll make my code shorter. But it makes the SQLite core code larger. Why should the the SQLite core be enlarged for the convenience of a single user. It's rather hard to say, if really just "single". SQLite, as I understood, has many users; just three of them were "against", until this time. Who knows, which of the existing features are used by how many users? Yesterday one of them wrote, that (if I properly understood) he appreciates nothing more, than "job of storage". 2. It'll make my life easier. ;) But it makes my life harder. [..] Probably a bit - but it was your own choice of such way of life, anyway. ;) You know, I believe that an "embedded" SQL has a philosophy which is inherently minimalist. Your request specifically goes against the philosophy of what SQLite was designed to be. DRH is working hard to protect an ideal which has appealed to millions, and continues to do so, and adding bloat will not contribute to its future success. There is nothing to top you from *FORKING* the SQLite project into a kitchen sink version of MySQL, PostGresql, Firebird or any of a number of existing full featured databases, and then *YOU* can be the one to determine what features belong in *YOUR* database managment system, and take on the work of implementing every idea which comes along ... Perhaps SQL_Obese? - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] "always-trim" - feature suggestion
On Wed, Jan 09, 2008 at 12:51:16PM +, [EMAIL PROTECTED] wrote:
> > Why not have a possibility to make it default
> > behaviour of the SQL-engine itself, just by
> > using one "pragma"?
> >
> > 1. It'll make my code shorter.
>
> But it makes the SQLite core code larger. Why should the the
> SQLite core be enlarged for the convenience of a single user.
It's rather hard to say, if really just "single". SQLite, as I understood,
has many users; just three of them were "against", until this time.
Who knows, which of the existing features are used by how many users?
Yesterday one of them wrote, that (if I properly understood) he appreciates
nothing more, than "job of storage".
> > 2. It'll make my life easier. ;)
>
> But it makes my life harder. [..]
Probably a bit - but it was your own choice of such way of life, anyway. ;)
> > 3. It'll make the inserting operation faster, than using separate trim-s for
> >every value, at SQL level.
>
> No it won't. The string has to be trimmed either way. Doing
> it explicitly or magically in the background does not change the
> amount of work that has to be done. The work does not go away
> just because you cannot see it.
I don't know SQLite internals - but I was supposing, that trimming inserted
strings "by default", without looking at the SQL sequence first ("does there
exist a `trim' for current string? Yes, so we're stripping spaces..., or
perhaps not?"), should make that operation faster.
Perhaps I was wrong, not knowing, as I wrote, the internals.
> > 4. It can be, as I wrote, additional safety, f.e. if I forgot to set trim
> >anywhere in the application.
>
> It might also introduce bugs, if for some reason you ever decide
> that you really want a space at the beginning of some field.
But I'm ready to take the risk.
> > 5. In some simpler cases I could even omit entry check knowing, that strings
> >will be trimmed by SQLite anyway.
>
> See #2
...
> > 6. It's a feature "in the spirit" of the one, which allows to insert strings
> >containing single quotes, without a need to escape them first (very
> >convenient! :)
>
> You can easily write your own sqlite3_bind_trimmedtext() interface
> to accomplish this. The sqlite3_bind_trimmedtext() would first trim
> spaces from both ends of the input string, then pass the result
> through to sqlite3_bind_text(). No changes to the SQLite core are
> needed to accomplish this.
Thanks, perhaps it's a way for me to have this. Although, pay attention,
you just wrote, that "it's easy and doesn't need significant changes".
> > 7. It won't hurt anybody; as I wrote, it would be an option. But I'm pretty
> >sure, many can (and will) appreciate that. Never seen that in any other
> >database server (or engine).
>
> No, it would hurt others. Everybody that uses SQLite would have to
> pay the penalty of a larger executable and a more complicated code
> base. True, the change would be small and would not by itself be
> a big deal. But hundreds of such changes would quickly balloon the
> size of the SQLite library and make it so complex that we would no
> longer be able to maintain it effectively.
I fully agree. But my suggestion was about just one change (and very small,
as you agreed) - not about hundreds. Besides: (almost) every introduced
feature makes the code more complex. Should the development of the
applications be stopped then?
OK, as I wrote already, it was just a proposal. The others may suggest this
or that - so I made use out of my freedom to make the same.
--
pozdrawiam / regards
Zbigniew Baniewski
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
Re: [sqlite] "always-trim" - feature suggestion
Zbigniew Baniewski <[EMAIL PROTECTED]> wrote: > > Why not have a possibility to make it default > behaviour of the SQL-engine itself, just by > using one "pragma"? > > 1. It'll make my code shorter. But it makes the SQLite core code larger. Why should the the SQLite core be enlarged for the convenience of a single user. > 2. It'll make my life easier. ;) But it makes my life harder. Not only do I have to develop a patch to the core to implement the requested feature, but I also have to develop test scripts to verify its correct operation, and I have to support and maintain this feature forever into the future. > 3. It'll make the inserting operation faster, than using separate trim-s for >every value, at SQL level. No it won't. The string has to be trimmed either way. Doing it explicitly or magically in the background does not change the amount of work that has to be done. The work does not go away just because you cannot see it. > 4. It can be, as I wrote, additional safety, f.e. if I forgot to set trim >anywhere in the application. It might also introduce bugs, if for some reason you ever decide that you really want a space at the beginning of some field. > 5. In some simpler cases I could even omit entry check knowing, that strings >will be trimmed by SQLite anyway. See #2 > 6. It's a feature "in the spirit" of the one, which allows to insert strings >containing single quotes, without a need to escape them first (very >convenient! :) You can easily write your own sqlite3_bind_trimmedtext() interface to accomplish this. The sqlite3_bind_trimmedtext() would first trim spaces from both ends of the input string, then pass the result through to sqlite3_bind_text(). No changes to the SQLite core are needed to accomplish this. > 7. It won't hurt anybody; as I wrote, it would be an option. But I'm pretty >sure, many can (and will) appreciate that. Never seen that in any other >database server (or engine). No, it would hurt others. Everybody that uses SQLite would have to pay the penalty of a larger executable and a more complicated code base. True, the change would be small and would not by itself be a big deal. But hundreds of such changes would quickly balloon the size of the SQLite library and make it so complex that we would no longer be able to maintain it effectively. -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] "always-trim" - feature suggestion
On Mon, Jan 07, 2008 at 11:37:25AM -0500, P Kishor wrote: > As someone said, the most bugfree code is the one that didn't have to > be written. While that is true from our perspective (let the db take > care of it), it is also true from the perspective of the makers of the > db (let the user take care of it). 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. Of course, it's just a suggestion. -- pozdrawiam / regards Zbigniew Baniewski - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] "always-trim" - feature suggestion
speaking for myself, and projecting on the makers of SQLite... On 1/7/08, Zbigniew Baniewski <[EMAIL PROTECTED]> wrote: > On Mon, Jan 07, 2008 at 03:59:52PM +, [EMAIL PROTECTED] wrote: > > > If you want to trim whitespace on insert, why not just say so: > > > >INSERT INTO table VALUES(trim(?),trim(?),trim(?)); > > > > Instead of: > > > >INSERT INTO table VALUES(?,?,?); > > Yes, yes - quite right. And exactly because of this I "invented" a feature > I'm suggesting now. In my practice, *always* I wanted to insert values > stripped out of spaces. So, when I know, that now and in the future I want > always to have these strings stripped out of spaces, why not have a > possibility to make it default behaviour of the SQL-engine itself, just by > using one "pragma"? because, while you and I might see the world and SQLite from our perspective, the makers of SQLite have to see the world from their and the world's perspective. Just like you might appreciate a specific feature, someone else might appreciate another specific feature. A feature here and a feature there, and soon we are talking about feature bloat. Generally, I assume, the rule is -- if it can be done some way, then do it that way without adding a feature. Each extra line of code is a possible source of bug, conflict, test failure, require comments, maintenance, has to not break backward compatibility, yadda yadda yadda. As someone said, the most bugfree code is the one that didn't have to be written. While that is true from our perspective (let the db take care of it), it is also true from the perspective of the makers of the db (let the user take care of it). > > 1. It'll make my code shorter. > 2. It'll make my life easier. ;) > 3. It'll make the inserting operation faster, than using separate trim-s for >every value, at SQL level. > 4. It can be, as I wrote, additional safety, f.e. if I forgot to set trim >anywhere in the application. > 5. In some simpler cases I could even omit entry check knowing, that strings >will be trimmed by SQLite anyway. > 6. It's a feature "in the spirit" of the one, which allows to insert strings >containing single quotes, without a need to escape them first (very >convenient! :) > 7. It won't hurt anybody; as I wrote, it would be an option. But I'm pretty >sure, many can (and will) appreciate that. Never seen that in any other >database server (or engine). > -- > pozdrawiam / regards > > Zbigniew Baniewski > > - > To unsubscribe, send email to [EMAIL PROTECTED] > - > > - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] "always-trim" - feature suggestion
On Mon, Jan 07, 2008 at 03:59:52PM +, [EMAIL PROTECTED] wrote: > If you want to trim whitespace on insert, why not just say so: > >INSERT INTO table VALUES(trim(?),trim(?),trim(?)); > > Instead of: > >INSERT INTO table VALUES(?,?,?); Yes, yes - quite right. And exactly because of this I "invented" a feature I'm suggesting now. In my practice, *always* I wanted to insert values stripped out of spaces. So, when I know, that now and in the future I want always to have these strings stripped out of spaces, why not have a possibility to make it default behaviour of the SQL-engine itself, just by using one "pragma"? 1. It'll make my code shorter. 2. It'll make my life easier. ;) 3. It'll make the inserting operation faster, than using separate trim-s for every value, at SQL level. 4. It can be, as I wrote, additional safety, f.e. if I forgot to set trim anywhere in the application. 5. In some simpler cases I could even omit entry check knowing, that strings will be trimmed by SQLite anyway. 6. It's a feature "in the spirit" of the one, which allows to insert strings containing single quotes, without a need to escape them first (very convenient! :) 7. It won't hurt anybody; as I wrote, it would be an option. But I'm pretty sure, many can (and will) appreciate that. Never seen that in any other database server (or engine). -- pozdrawiam / regards Zbigniew Baniewski - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] "always-trim" - feature suggestion
Ken <[EMAIL PROTECTED]> wrote: > > I don't think sqlite supports column level check contstraints. > SQLite has supported CHECK constraints since version 3.0.0, released one year ago this coming Thursday. On the other hand, a CHECK constraint cannot modify data going into a table. It will only block the insertion if the data is not well-formed. If you want to trim whitespace on insert, why not just say so: INSERT INTO table VALUES(trim(?),trim(?),trim(?)); Instead of: INSERT INTO table VALUES(?,?,?); SQLite allows arbitrary expressions in the VALUES clause of an insert. -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] "always-trim" - feature suggestion
Thats when a trigger or application code should be used. 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. The database is intended for data storage. Not data cleanup. This goes pretty much for every commercial database out there as well. Ken Zbigniew Baniewski <[EMAIL PROTECTED]> wrote: On Sun, Jan 06, 2008 at 07:39:55PM -0800, Darren Duncan wrote: > I think that this would be a horrible thing if it were the default > behaviour. A database needs to by default store and retrieve data > pristine , so that people get out what they put in, not something > else. And when the people - just by their intention - deliberately want to strip *every* stored string? Wouldn't be this much smarter done such way? > Or if you really have to have the pragma, it needs to be off by default. Yes, that's what I'm suggesting: to add an option, which could change default, just "for those about to trimming". It could (perhaps even should) be "off" by default. -- pozdrawiam / regards Zbigniew Baniewski - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] "always-trim" - feature suggestion
On Sun, Jan 06, 2008 at 07:39:55PM -0800, Darren Duncan wrote: > I think that this would be a horrible thing if it were the default > behaviour. A database needs to by default store and retrieve data > pristine , so that people get out what they put in, not something > else. And when the people - just by their intention - deliberately want to strip *every* stored string? Wouldn't be this much smarter done such way? > Or if you really have to have the pragma, it needs to be off by default. Yes, that's what I'm suggesting: to add an option, which could change default, just "for those about to trimming". It could (perhaps even should) be "off" by default. -- pozdrawiam / regards Zbigniew Baniewski - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] "always-trim" - feature suggestion
At 3:28 AM +0100 1/7/08, Zbigniew Baniewski wrote: 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. But perhaps even not just only as "secondary"? Yes, usually it's done at application level; I was wondering lately, why not "from the other end"? Seems to not be that difficult to implement. In fact, almost always we want to insert into database the strings with no spaces at beginning, neither at the end - so perhaps adding a possibility to set such behaviour (using "pragma") as "default" seems to be logical? What do you think? I think that this would be a horrible thing if it were the default behaviour. A database needs to by default store and retrieve data pristine , so that people get out what they put in, not something else. Leading/trailing spaces *are* significant for character strings, eg, 'foo ' is not supposed to equal 'foo'. Better for for any changes to the data in the DBMS to be explicit, like by using an explicit trim() function at the appropriate times, or implementing a trigger routine or stored procedure that handles it. Or if you really have to have the pragma, it needs to be off by default. -- Darren Duncan - To unsubscribe, send email to [EMAIL PROTECTED] -
