sqlite is typeless....
I have addressed this issue in the following HOWTO:....
http://www.mail-archive.com/sqlite-users@sqlite.org/msg03205.html
Please refer to it.
Tezozomoc.
----Original Message Follows----
From: Darren Duncan <[EMAIL PROTECTED]>
Reply-To: sqlite-users@sqlite.org
To: sqlite-users@sqlite.org, Matt Sergeant <[EMAIL PROTECTED]>
Subject: Re: [sqlite] preventing text to integer conversion of bind
variables in perl
Date: Wed, 15 Jun 2005 17:45:44 -0700
At 11:39 AM -0400 6/15/05, Matt Sergeant wrote:
I added it because of another bug report that was incorrectly sorting
integer columns based on text sort order. For example if you inserted:
("k1", 8);
("k2", 9);
("k3", 10);
("k4", 11);
and then asked for: SELECT * FROM t ORDER BY Column2
you get back:
k3, 10
k4, 11
k1, 8
k2, 9
Which seems obviously incorrect.
In answer to your question though, yes you can remove that bit of code, as
long as you're aware of the above side effect.
Well, if Column2 is explicitly defined as an integer, then it should always
sort as an integer, and making that work is the responsibility of SQLite
itself.
I see that preserving the input data in all situations where the declared
column type can handle it is of the utmost importance, and DBD::SQLite
should do this.
So I vote to remove any de-stringification code you have in DBD::SQLite.
To be honest I'm not entirely sure what the correct fix is - maybe ignore
the above bug and tell the requestor he has to: SELECT * FROM t ORDER BY
int(Column2)
Yes, go ahead and do that. Alternately, tell the person to use SQLite in
strict mode so that it only ever stores ints in int columns. Like most
databases do.
Matt, I would also appreciate it if a new DBD::SQLite was released asap that
embeds and is known to work well with the 3.2 series, specifically 3.2.2.
Thank you in advance.
-- Darren Duncan
