I don't. I suggest that each wrapper be adapted to its purpose. Light,
heavy, high level, low level or whatever. In other words use the
toolkit as a kit of tools.
Joe Wilson wrote:
How do you propose that someone adds support for an official SQLite DATE
type in the 100 or so SQLite wrappers/drivers for various languages
and operating systems to get them all to agree on this standard DATE type?
Only by making an official SQLite DATE type in the SQLite distro
can you acheive this. What code I may write in my wrapper is irrelevant
if I try to open my database with another wrapper that I did not
write.
The truth is it's probably too late for SQLite3 to have an official
DATE type since the API is more or less frozen. Such a new type could
only be added in a hypothetical SQlite4 - which may never happen.
I give up.
--- John Stanton <[EMAIL PROTECTED]> wrote:
If drivers and such concern you the solution is obvious, implement the
DATE type in the driver or "wrapper". Sqlite's basic architecture makes
it simple.
The Sqlite library is correct in being light and biased towards a small
footprint for embedded applications. Adding layers of software to
implement extra functions, interfaces etc is no problem, it is the way
it is intended to be used.
Joe Wilson wrote:
SQLite advocacy aside, I was just addressing your original statement:
Most Sqlite users know that Sqlite implements a DATE type
which is not strictly true.
Me, you and most SQLite users have seperately come up with conventions
to handle their particular date usage patterns. There is no disputing
the value of the sqlite date functions.
While conventions are fine for individual applications, sometimes policy
is necessary for such things as database drivers (JDBC and ODBC being
the most common). SQLite's manifest typing sometimes cause the various
3rd party drivers to represent date columns as different types and values.
In one driver a DATE is represented as TEXT, another as some form of
DATE. Each driver makes assumptions about how dates are handled
and converted to/from test. Sometimes these assumptions are correct and
sometimes they are wrong. There's no way a third-party driver can possibly
know what is in the mind of an individual SQLite database designer and what
intent they had for a particular date field. If SQLite supported an official
DATE type, such inconsistancies could be avoided, and the underlying storage
of DATEs could be consistant across all applications and could potentially
be stored in a more space-efficient form in the database file, as an added
bonus.
--- John Stanton <[EMAIL PROTECTED]> wrote:
From my perspective Sqlite does implement a DATE type by having the
function support for an epoch based date stored in a floating point
number plus declared types. The Sqlite epoch appears to be the
theoretically correct one based on an epoch somewhere in antiquity and
compatible with all the world's significant calendars.
[...]
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
