Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

jdavidb (1361)

jdavidb
  (email not shown publicly)
http://voiceofjohn.blogspot.com/

J. David Blackstone has a Bachelor of Science in Computer Science and Engineering and nine years of experience at a wireless telecommunications company, where he learned Perl and never looked back. J. David has an advantage in that he works really hard, he has a passion for writing good software, and he knows many of the world's best Perl programmers.

Journal of jdavidb (1361)

Thursday December 19, 2002
11:52 AM

Strong feelings about strong typing

[ #9548 ]

Similar to Perl, SQLite doesn't do strong typing. They seem rather militant about it, in fact.

This behavior is a feature, not a bug. A database is suppose [sic] to store and retrieve data and it should not matter to the database what format that data is in. The strong typing system found in most other SQL engines and codified in the SQL language spec is a misfeature - it is an example of the implementation showing through into the interface.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Probably the one datatype that I would have a very hard time living without would be the 'date' type. I run lots of queries where I need "date > sysdate-3" or whatever.

    Having to parse out dates and calculate date differences manually would be a serious PITA.

    Or does SQLite have a way to do this? I haven't looked.

    • I don't know about SQLite, but Perl gives me date arithmetic with Matt Sergeant's Time::Piece. I've had decent luck doing date parsing when needed with HTTP::Date.

      I would just as soon DBI queries give me date values as a Time::Piece.

      --
      J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
      • For that matter, barring the troubles of parsing the user input, if SQLite doesn't do dates and I need them, I would use Time::Piece objects on the Perl side and convert them to epochtime for storage on the DB side. Conversion to and from epochtime is simple with Time::Piece, arithmetic and comparisons are simple, and output formatting is simple.

        Hmmm, date parsing would seem to be the only thing Time::Piece is lacking...

        --
        J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
        • I use Time::ParseDate with Time::Piece when strptime isn't going to work well.

          Time::ParseDate adds a bit of overhead though, so I try to use strptime where I can rely on dates coming back in a specific format (like date values from a database).

          --

          -- tex