> -----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 ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
