From: Simon Wistow Date: 11:17 on 25 May 2005 Subject: SQLite and friends I know that at least one other member of our carthartic little bile cabal has come across this problem http://use.perl.org/~hex/journal/24191 but some combination of Class::DBI, DBI, DBD::SQLite and sqlite is fucking up my cabbage patch. I'm using SQLite for rapid prototyping and I want to stick a version into a DB. A version is a string because, well, apparently just having incrementing numbers is too difficult for people or something. Either way, this shouldn't be a problem. Right? Right? Just set the column type to VARCHAR. Or TEXT. Or BLOB. Or CLOB. Any of those? No. SQLite trys to promote whatever goes in to be a number. Despite claiming that it won't "If the datatype of the column contains any of the strings "CHAR", "CLOB", or "TEXT" then that column has TEXT affinity. Notice that the type VARCHAR contains the string "CHAR" and is thus assigned TEXT affinity. If the datatype for a column contains the string "BLOB" or if no datatype is specified then the column has affinity NONE." http://www.sqlite.org/datatype3.html MY SCHEME DOES DEFINE IT AS ONE OF THOSE! YOU SYPHILLITIC PILE OF GYM SOCKS! In fact I've tried everyone of those and also the trick of manually and explicitly setting the data type to be BLOB. But no. Apparently the simple taks of sticking exactly what I want into the database is too difficult. I apparently misunderstood the point of a database - here I was thinking that it was store data and, in fact, it's intended purpose is TO MAKE MY LIFE A MISERY. *sigh*
From: Nicholas Clark Date: 11:26 on 25 May 2005 Subject: Re: SQLite and friends On Wed, May 25, 2005 at 11:17:51AM +0100, Simon Wistow wrote: > MY SCHEME DOES DEFINE IT AS ONE OF THOSE! YOU SYPHILLITIC PILE OF GYM > SOCKS! How is syphilis transmitted via socks? I thought... Er, maybe I don't ask. Nicholas Clark
From: Greg McCarroll Date: 11:28 on 25 May 2005 Subject: Re: SQLite and friends On 25 May 2005, at 11:26, Nicholas Clark wrote: > On Wed, May 25, 2005 at 11:17:51AM +0100, Simon Wistow wrote: >> MY SCHEME DOES DEFINE IT AS ONE OF THOSE! YOU SYPHILLITIC PILE OF GYM >> SOCKS! > > How is syphilis transmitted via socks? I thought... > Er, maybe I don't ask. this one time, at band camp ... W.
From: peter (Peter da Silva) Date: 14:56 on 25 May 2005 Subject: Re: SQLite and friends > SQLite trys to promote whatever goes in to be a number. Despite claiming > that it won't IIRC, SQLite doesn't really do data types. Sure your Perl wrapper isn't doing something horrid to you? My current problem with SQLite, for example, is in its Tcl binding. The underlying code can do what I want, but it's not exposed to the Tcl code. > http://www.sqlite.org/datatype3.html From my reading of this page, if you do INSERT INTO foo VALUES('1.0',1.0); then the first will be TEXT, the second NUMERIC. If you're using quotes selectively (for example, just to quote strings for security), then your version number will go in as an integer. Column affinity may THEN turn it back into another data type. Thanks for bringing this up, my code currently quotes everything, and I'll have to leave integers unquoted if I switch to SQLite.
From: Chris Devers Date: 16:26 on 25 May 2005 Subject: Re: SQLite and friends On Wed, 25 May 2005, Simon Wistow wrote: > I'm using SQLite for rapid prototyping ...and now you see why it probably isn't appropriate for anything other than rapid prototyping. SQLite. Because MySQL just wasn't "sql access to your filesystem"-enough for some people. Because MySQL just wasn't "it's fast because it's broken"-enough for some people. Because, for some people, "cheap" and "fast" trump "correct". Because doing data management right IS FOR SLOWPOKE NINNIES.
From: Matt McLeod Date: 03:05 on 26 May 2005 Subject: Re: SQLite and friends Chris Devers wrote: > On Wed, 25 May 2005, Simon Wistow wrote: > > > I'm using SQLite for rapid prototyping > > ...and now you see why it probably isn't appropriate for anything other > than rapid prototyping. There are cases where you want some pretty basic data storage, don't want to depend on having a server running, and would like to use SQL for queries anyway. A package manager would be a good example of something where SQLite isn't as bad a choice as you make it sound. That said, we reject lots of open source packages as possible solutions because they depend on MySQL. If you have to stuff data in a real database (and we'd rather you didn't, usually) then it's Postgres, Ingres, or nothing at all. For me, MySQL hate is about people doing stupid shit with it that would've been better off either not in a database at all or in a real database. SQLite is better suited to much of the former category. Matt (A monitoring system that requires MySQL? Why, what a clever idea! So what happens to your monitoring when MySQL is being updated?)
From: peter (Peter da Silva) Date: 17:10 on 25 May 2005 Subject: Re: SQLite and friends > SQLite. > Because MySQL just wasn't "sql access to your filesystem"-enough > for some people. Well, no, it's not, in fact I'm not sure that SQLite is fast enough for our application, even using an in-core database and precompiled queries. We're comparing SQLite and Metakit right now, and the advantage of SQLite is that we can share more code between the front-end and the back-end. > Because doing data management right IS FOR SLOWPOKE NINNIES. Well, doing data management "right" kind of depends on what kind of software you're writing. I don't think I'd want to use Postgres in a handheld or the front end of a control system, even when it's got a UNIX base.
Generated at 10:27 on 16 Apr 2008 by mariachi