Robert Simpson wrote:
-----Original Message-----
From: John Stanton [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 31, 2007 4:08 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Re: CAST
You have explained the problem, which is .NET not Sqlite. You have
apparently done a fine job marrying the two but it might be more
logical
to suggest that .NET be made more flexible.
As for flexibility, programs in C or Assembler are only inflexible at
the level of the underlying machine or operating system. They are a
tool to use to build an environment.
Initially the typing rules in Sqlite appeared to be a nusisance but on
deeper thought their utility became apparent and it was possible to use
them to great advantage. To bloat or impair that advantage just to
match a particular concept like .NET would be a tragedy.
You might consider developing an SQL engine ideally adapted to .NET.
I don't really know how we got here :) I think SQLite is a fantastic engine,
fast, free and flexible -- I wouldn't have spent the last 2 years
maintaining an ADO.NET provider for it if I didn't love it. I'm certainly
not going to throw the baby out with the bath water and try and roll my own
SQL engine -- it misses the point entirely. I'm here to support SQLite.
I'm not complaining about SQLite's lack of typing in general. Could I use a
little help in making SQLite fit more seamlessly into these typed
environments? Sure, the more help I get the better!
I'd love it if I could issue a CAST([MyCol] AS HAIRYLLAMA) and have some way
to yank HAIRYLLAMA out of the statement's metadata so I could tell what
specific type that column was CAST to.
Heck, I'd love it even more if there was an additional parameter in the
user-def function callback to provide SQLite a string name of a type
returned from a function so we could have more descriptive typing in there
as well.
The problem isn't .NET. The problem is that every other database on the
planet enforces type restrictions, and hence every generic database access
layer (ODBC, OLEDB, ADO, ADO.NET) is designed around that concept. "Don't
use a wrapper" doesn't work for every circumstance, and I can't change the
ADO.NET spec -- though I do get around it where I can to support SQLite's
typelessness.
My opinion is: Since SQLite is typeless, then it should probably have a few
more functions dedicated to type description. Preserving the destination
typename on a CAST as well as in a userdef function would go a long way
toward accomplishing that. Or even better, some kind of extensible type
system that enabled us to have type-specific comparison callbacks.
However -- we're not there, and may never get there, so I'll continue to
hack. That's what open source is for, afterall :)
Robert
There was a lot of fuss on the financial news tonight concerning Google
Gears and its impact. Sergey Brin was interviewed saying guilelessly
that Google doesn't think of other companies, only users but the
resident experts were saying that this is a blow at Microsoft.
Its is significant that the Sqlite based Google Gears seems to take
advantage of typeless storage to produce a more general storage model.
That was the point of my comments, Sqlite lets us advance our storage
capabilities into a more flexible world.
The way we have chosen to use Sqlite has many parallels with the Google
approach, presumably a logical development of the storage concepts.
We use PostgreSQL to map into environments requiring its capabilities
and Sqlite where it fits well, such as in an application specific
language we developed and with Javascript. We don't use TCL but I
understand it matches beautifully with Sqlite, by design.
If we were to rigidly lock into existing technologies we would still be
using punch cards or perhaps clay tablets.
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
