A. Pagaltzis schrieb:
* Samuel R. Neff <[EMAIL PROTECTED]> [2007-05-30 14:55]:
SQLite's typelessness is an asset if you work only with SQLite
but in any application that uses multiple database engines of
which SQLite is only one supported engine, the non-standard
typelessness is something that has to be worked around.
Can you give an example of such a case? I work with several
different DBMSs, myself, and I have yet to run into trouble with
SQLite’s approach. Can you give a reallife example?
Start by already having a wrapper that allows type introspection (
e.g. DESCRIBE on oracle and reading the result set to find out what types are
returned)
such a feature is basically non-portable to SQLite.
This works fine if one gets the data direct from a table with declared types,
which are
introspectable, but it breaks as soon as computed results (aggregates or other)
are
included.
Basically user code fires any odd SQL at the database and expects to get a
table structure with data
cast correctly to the 'wrapper native' datatypes. Declaring the expected types
for the resulting row
would work, but if the wrapper only supports the introspectiv result binding
and you have some 100k
lines of code using the wrapper you have a problem with the sqlite approach.
(its a problem with the wrapper APIs/usage, not really with SQLite)
Michael
--
Michael Schlenker
Software Engineer
CONTACT Software GmbH Tel.: +49 (421) 20153-80
Wiener Straße 1-3 Fax: +49 (421) 20153-41
28359 Bremen
http://www.contact.de/ E-Mail: [EMAIL PROTECTED]
Sitz der Gesellschaft: Bremen | Geschäftsführer: Karl Heinz Zachries
Eingetragen im Handelsregister des Amtsgerichts Bremen unter HRB 13215
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
