Re: [sqlite] type confusion
On 11/3/05, Dennis Cote <[EMAIL PROTECTED]> wrote: > I agree that moving away from the standard is a bad thing, but this > change does not in any way merit forking SQLite or changing its name. > SQLite currently deviates from the standard in much more significant > ways than this proposed (well its more than proposed now) change. It > lacks many standard functions, has no support for standard dates or > times, and no support for referential integrity for example. An excellent point, one that I didn't consider. > In summary: SQLite is good. Standards are good. I hope SQLite moves > towards the SQL standard. I agree. I wanted to suggest that if the design goals are changing and DRH is headed in a different direction he should put on his turn signals... Seems it's overwhelming not a popular idea ;) I'm sure a lot of people would benefit from the typeless version.
Re: [sqlite] type confusion
Jay Sprenkle wrote: Since SQL conformance is hard to legitimately define (Are we going to conform to cj date, mysql, oracle, etc.) you're right, it would be hard. I believe my original suggestion still has value: If DRH is going to radically change SQLite (removing/redefining typing and redoing the expression evaluation) then a split/branch is valuable. Jay, I agree that moving away from the standard is a bad thing, but this change does not in any way merit forking SQLite or changing its name. SQLite currently deviates from the standard in much more significant ways than this proposed (well its more than proposed now) change. It lacks many standard functions, has no support for standard dates or times, and no support for referential integrity for example. SQLite currently covers a very large subset of standard SQL, and most of the recent changes have been made in a way that makes it more standard compliant. The recent changes to NULL handling in the SUM function and the addition or correlated subqueries come to mind. One of the things I see happening repeatedly around here is the comparison of one SQL implementation to another. We are often asked how does database X (or X, Y, and Z) do this. Also, people often justify deviation from the standard because other databases also deviate from the standard (perhaps even in different ways). The solution to the compatibility problem is not to try match the behavior of another database, but rather to match the behavior required by the standard. If all the database implementations do this (and I believe that most are generally trying to), then they will all eventually become more and more compatible with each other as time goes on. At some point the differences will be so small that they are seldom an issue. This will only be achieved if we continuously aim for standard compliance. It is the target we should alway try to move towards, never away from. Many of the things we use everyday work only because all implementors adhere to a common standard. Threading of nuts and bolts, USB devices, compact disks, the C programming language, etc.as examples. These things work well and interoperate because all implementors work from a common standard. I'm sure each of these standards have some warts that could be improved. Generally fixing these problems isn't worth the loss of compatibility so all implementations live with warts until a consensus arises that the standard itself should be changed. At that point all implementation can be revised at nearly the same time so the improvement is realized without an attendant loss of compatibility. Many good ideas have been sacrificed to maintain compatibility, but the increased usability of compatible products is usually worth the sacrifice. Truly great ideas often form the basis for a totally new way of doing things which is completely incompatible with the previous technology. Usually, these ideas will develop their own standard to ensure compatibility between implementations. I think this change is a good idea that should have been sacrificed for compatibility. It's not such a great idea that it will spawn a whole new industry centered around typeless databases engines. As a result of this chnage SQLite has become a slightly less compatible database engine. Well this post certainly drifted away from where I started but at least that is off my chest. In summary: SQLite is good. Standards are good. I hope SQLite moves towards the SQL standard. Dennis Cote
Re: [sqlite] type confusion
You might be right. It might be a good thing though. If nobody wants the compliance/efficiency version then the other branch isn't burdened with all the compliance code. It's DRH's decision and I've put in my two cents worth. Hopefully nobody has gone away with hard feelings. On 11/3/05, Fred Williams <[EMAIL PROTECTED]> wrote: > I hate to duplicate code! How 'bout looking at a "STRICT SQL" Pragma? > Still sounds like a lot of work, and some level of footprint bloat, but > at least work continues on a single code base. I predict that both > branches of the proposed spilt will suffer and one or both will > eventually wither and die. > > Fred > > > -Original Message- > > From: Jay Sprenkle [mailto:[EMAIL PROTECTED] > > Sent: Thursday, November 03, 2005 9:35 AM > > To: sqlite-users@sqlite.org > > Subject: Re: [sqlite] type confusion > > > > > > Since SQL conformance is hard to legitimately define (Are we > > going to conform to cj date, mysql, oracle, etc.) you're right, > > it would be hard. > > > > I believe my original suggestion still has value: > > > > If DRH is going to radically change SQLite (removing/redefining typing > > and redoing the expression evaluation) then a split/branch is > > valuable. > > > > Freeze the existing code in place for people who want conformance > > or efficiency. That isn't a significant amount of work. If > > DRH wants it can be > > updated with code changes from his active development branch. > > I'd be willing to contribute to the old branch since it has > > value to me. > > > > Since the new branch is NOT significantly like SQL it should get > > a new name. Maybe "ObjectBase" (or insert your own name here). > > I'm ignoring "branding" issues for the sake of a descriptive moniker. > > > > DRH gets what he wants, the people doing embedded and conversion > > projects get what they want. It's not a significant amount of > > extra work > > unless DRH wants to make it so. The design goals of both projects are > > clearly spelled out. Both groups are supplied with a tool > > that doesn't do everything well, but does what it does very well. > > > > > > On 11/3/05, Joe Wilson <[EMAIL PROTECTED]> wrote: > > > Your suggestions would require a lot of work. Considering this > > > free software I thought you would like to spearhead this SQL > > > conformance effort. I think it would be very valuable. > > > > > > --- Jay Sprenkle <[EMAIL PROTECTED]> wrote: > > > > > > > > We look forward to your standards compliance branch, Jay. > > > > > Please tell us when we can expect to download your version. > > > > > > > > DRH suggested a change, I put in my two cents since his message > > > > included a call for commentary. If you don't like the > > suggestion please > > > > feel free to ignore it or give a reasonable explanation > > of why it's not a > > > > good idea. I don't believe insults are a reasonable > > response? Do you? > > > > Do you have anything positive to contribute? > > > > > > > > > > > > > > > > > > > > > > __ > > > Yahoo! Mail - PC Magazine Editors' Choice 2005 > > > http://mail.yahoo.com > > > > > > > > > -- > > --- > > The Castles of Dereth Calendar: a tour of the art and architecture of > > Asheron's Call > > http://www.lulu.com/content/77264 > > -- --- The Castles of Dereth Calendar: a tour of the art and architecture of Asheron's Call http://www.lulu.com/content/77264
RE: [sqlite] type confusion
I hate to duplicate code! How 'bout looking at a "STRICT SQL" Pragma? Still sounds like a lot of work, and some level of footprint bloat, but at least work continues on a single code base. I predict that both branches of the proposed spilt will suffer and one or both will eventually wither and die. Fred > -Original Message- > From: Jay Sprenkle [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 03, 2005 9:35 AM > To: sqlite-users@sqlite.org > Subject: Re: [sqlite] type confusion > > > Since SQL conformance is hard to legitimately define (Are we > going to conform to cj date, mysql, oracle, etc.) you're right, > it would be hard. > > I believe my original suggestion still has value: > > If DRH is going to radically change SQLite (removing/redefining typing > and redoing the expression evaluation) then a split/branch is > valuable. > > Freeze the existing code in place for people who want conformance > or efficiency. That isn't a significant amount of work. If > DRH wants it can be > updated with code changes from his active development branch. > I'd be willing to contribute to the old branch since it has > value to me. > > Since the new branch is NOT significantly like SQL it should get > a new name. Maybe "ObjectBase" (or insert your own name here). > I'm ignoring "branding" issues for the sake of a descriptive moniker. > > DRH gets what he wants, the people doing embedded and conversion > projects get what they want. It's not a significant amount of > extra work > unless DRH wants to make it so. The design goals of both projects are > clearly spelled out. Both groups are supplied with a tool > that doesn't do everything well, but does what it does very well. > > > On 11/3/05, Joe Wilson <[EMAIL PROTECTED]> wrote: > > Your suggestions would require a lot of work. Considering this > > free software I thought you would like to spearhead this SQL > > conformance effort. I think it would be very valuable. > > > > --- Jay Sprenkle <[EMAIL PROTECTED]> wrote: > > > > > > We look forward to your standards compliance branch, Jay. > > > > Please tell us when we can expect to download your version. > > > > > > DRH suggested a change, I put in my two cents since his message > > > included a call for commentary. If you don't like the > suggestion please > > > feel free to ignore it or give a reasonable explanation > of why it's not a > > > good idea. I don't believe insults are a reasonable > response? Do you? > > > Do you have anything positive to contribute? > > > > > > > > > > > > > > > __ > > Yahoo! Mail - PC Magazine Editors' Choice 2005 > > http://mail.yahoo.com > > > > > -- > --- > The Castles of Dereth Calendar: a tour of the art and architecture of > Asheron's Call > http://www.lulu.com/content/77264
Re: [sqlite] type confusion
Since SQL conformance is hard to legitimately define (Are we going to conform to cj date, mysql, oracle, etc.) you're right, it would be hard. I believe my original suggestion still has value: If DRH is going to radically change SQLite (removing/redefining typing and redoing the expression evaluation) then a split/branch is valuable. Freeze the existing code in place for people who want conformance or efficiency. That isn't a significant amount of work. If DRH wants it can be updated with code changes from his active development branch. I'd be willing to contribute to the old branch since it has value to me. Since the new branch is NOT significantly like SQL it should get a new name. Maybe "ObjectBase" (or insert your own name here). I'm ignoring "branding" issues for the sake of a descriptive moniker. DRH gets what he wants, the people doing embedded and conversion projects get what they want. It's not a significant amount of extra work unless DRH wants to make it so. The design goals of both projects are clearly spelled out. Both groups are supplied with a tool that doesn't do everything well, but does what it does very well. On 11/3/05, Joe Wilson <[EMAIL PROTECTED]> wrote: > Your suggestions would require a lot of work. Considering this > free software I thought you would like to spearhead this SQL > conformance effort. I think it would be very valuable. > > --- Jay Sprenkle <[EMAIL PROTECTED]> wrote: > > > > We look forward to your standards compliance branch, Jay. > > > Please tell us when we can expect to download your version. > > > > DRH suggested a change, I put in my two cents since his message > > included a call for commentary. If you don't like the suggestion please > > feel free to ignore it or give a reasonable explanation of why it's not a > > good idea. I don't believe insults are a reasonable response? Do you? > > Do you have anything positive to contribute? > > > > > > > > __ > Yahoo! Mail - PC Magazine Editors' Choice 2005 > http://mail.yahoo.com > -- --- The Castles of Dereth Calendar: a tour of the art and architecture of Asheron's Call http://www.lulu.com/content/77264
Re: [sqlite] type confusion
Your suggestions would require a lot of work. Considering this free software I thought you would like to spearhead this SQL conformance effort. I think it would be very valuable. --- Jay Sprenkle <[EMAIL PROTECTED]> wrote: > > We look forward to your standards compliance branch, Jay. > > Please tell us when we can expect to download your version. > > DRH suggested a change, I put in my two cents since his message > included a call for commentary. If you don't like the suggestion please > feel free to ignore it or give a reasonable explanation of why it's not a > good idea. I don't believe insults are a reasonable response? Do you? > Do you have anything positive to contribute? > __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
Re: [sqlite] type confusion
> We look forward to your standards compliance branch, Jay. > Please tell us when we can expect to download your version. DRH suggested a change, I put in my two cents since his message included a call for commentary. If you don't like the suggestion please feel free to ignore it or give a reasonable explanation of why it's not a good idea. I don't believe insults are a reasonable response? Do you? Do you have anything positive to contribute?
Re: [sqlite] type confusion
We look forward to your standards compliance branch, Jay. Please tell us when we can expect to download your version. --- Jay Sprenkle <[EMAIL PROTECTED]> wrote: > I proposed splitting the project into two branches so people who wanted > standards compliance and the people who wanted ease of programming > could both have what they wanted. The suggestion was called "lame" > and "purist fetishism". Why does everyone insist on having only one > tool in their toolbox and trying to use it for everything even when it's not > suited for it? I don't suppose I should suggest an easy programming > vs an efficient version either? They're fundamentally different goals > and need different solutions. __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
Re: [sqlite] type confusion
> > Subject: Re: [sqlite] Proposed 3.3.0 changes. Was: 5/2==2 > > > > So don't make the field 10 bytes long, make it only 8. SQLite won't > > > care a bit, and will give you the value in whatever format you want. > > > > Then it's not type agnostic any more. You now have an 8 byte numeric > > and a 10 byte numeric. Which is no different than integer and real. > > Wrong, and obviously so. I mean really, how many bytes LONG a value > is must DETERMINE whether it represents an integer or a floating point > number? Must? In what bizarre alternate universe is that true? You're so garbled here I'm not sure what you're trying to say. Here's the premise as I understood it: "All division operations should be performed identically." From: > > Am I alone in thinking that a division operator that does different > > things depending on the declared datatype of a column is an > > abomination? Examing that proposal: Some basic math theory: 2 / 3 If your division result is an integer you lose precision. 2/3 = . -> 0. becomes zero when assigned to an integer. Therefore: you must use floating point for all results since you're only allowed to have one way to divide. We can't do conversions since that breaks the premise of "one way to divide". The poster doesn't want conversions. Conclusion: In order to have one method for division, and not lose precision, and not have conversions, you must use floating point results for all numeric calculations. You have to do conversions to a common type and possibly conversions back to the destination type. Well, to be accurate, you could if you have only one numeric type, floating point. Most Interpreted languages, and sql engines, hide this basic fact by doing the conversions invisibly, like: SELECT 5/'2' . (See end of message for references) If you have an untyped database or language it converts the operands from variant to a numeric internally, then does the math, then converts it back to a variant again. I think the original poster's real complaint is that the coversions weren't done automatically and it was too much effort for him to learn to do it. My response to the proposed "typeless database with automatic conversion": Unless you can come up with a variant class as space efficient as the types it replaces what's the advantage? You use more storage (the variant represenation is larger) and have a slower system (longer retrieval because of more data + slower calculations). The choice of typing or not comes down to Efficiency versus Ease of programming. I thought the basic idea of SQLite was to be fast and light. "Typeless SQLite" seems to be a step backward from efficiency in both areas to me. I proposed splitting the project into two branches so people who wanted standards compliance and the people who wanted ease of programming could both have what they wanted. The suggestion was called "lame" and "purist fetishism". Why does everyone insist on having only one tool in their toolbox and trying to use it for everything even when it's not suited for it? I don't suppose I should suggest an easy programming vs an efficient version either? They're fundamentally different goals and need different solutions. > > > > From SQLite's standpoint it is agnostic. SQLite neither knows nor cares > > > what is actually stored in the column; that's up to your application to > > > The only way for this to work will be to remove all mathematic > > operations. You can't make it agnostic of types if you have more > > than one type and allow operations to be performed on the types. > > Again wrong. You missed the assumption at the beginning of the thread. > > (Note that deciding to do math on values, even if you do it via the > "+" operator in a SQL query, *IS* part of the application. It's > certainly not part of the data storage layer, at any rate.) SELECT 5/2; Is not evaluated by the application. Maybe you meant to say it "ought to be part of the application"? Or by "data layer" you mean Sqlite? > > Jay, it's painful to see you put your foot in your mouth over and over > again. Please learn enough so that you stop sticking it in there. I've been trying to not be unpleasant. I'm sorry you can't do the same. Perhaps you should take more time to cool off before posting. If you have a logical argument, rather than insults, I'm perfectly willing to listen. I think we're talking about different things here. I'm trying to understand your point, but are you trying to understand mine? > > E.g., Tcl can be reasonably described as type agnostic, yet it can do > math. Since DRH is also a member of the Tcl Core Team, presumably Tcl > was a design influence on SQLite. It might be useful to look at it > for comparison. You missed the basic assumption that conversions aren't allowed. References on conversion: TCL: The very first google result on "tcl arithmetic conversion" returns someone complaining about conversions not working well: "Abstract This TIP
