has_many :thoughts

I recently discovered that sqlite3 has a number of output modes to spit out query results in different formats:

.mode MODE ?TABLE?   Set output mode where MODE is one of:

csv      Comma-separated values
column   Left-aligned columns.  (See .width)
html     HTML <table> code
insert   SQL insert statements for TABLE
line     One value per line
list     Values delimited by .separator string
tabs     Tab-separated values
tcl      TCL list elements

By specifying .mode insert one can get nicely formatted insert statements that can be imported right into MySQL. This is what I did to convert my Voicemail app to MySQL. However, if you don’t specify a table name on the same line, the resulting insert statements just say “insert into table”. One must use .mode insert voicemails to get insert statements out of sqlite3 that read “insert into voicemails”. A bit silly if you ask me… one would think the table name in the insert statements would just default to the name of the table you were selecting from. But, this worked great for me and was all I needed to get converted.

The first time I heard of Camping, was Evan Weaver’s talk about it at Philly on Rails. I’ll admit that, at first, I was a bit skeptical. It seemed silly to have something that duplicated some of what Rails already did.

But I just built my first little app with Camping and I am pleasantly surprised. It was a just a little weekend project: A page that lists things in and around Philly that my wife and I like to do and can suggest to friends visiting the area. It has only one view to List out the items and a simple Add and Remove action. The database is sqlite, my first time using it.

Building it in Rails would probably have been overkill. Now, I still haven’t figured out the best way to deploy this on our server: I’m thinking I’ll try FastCGI. But the development process has been a joy and I love how everything is just one file of about 100 lines of code. (Except for, of course, Ruby, Camping, ActiveRecord, and a bunch of other libraries.)

Markaby was the most interesting thing to learn. I haven’t compared it thoroughly to HAML, which I’ve tried and do like, but it seems to be quite similar and just as fun to write with.

After reading about the wonderful release of mother Joyent’s Slingshot the other day, I noticed that in the docs it said Slingshot uses SQLite on desktop clients. I thought that this was pertaining to personal preference, support the underdog kinda thing. That was wrong, SQLite is easier on memory because it uses file-io instead of in-memory db access…

“For low load websites, SQLite has worked great in our projects. If you’re doing an application in C, its API is simply unbeatable. Perhaps its most distinguishing feature is that it pretty much ignores types. This is, in fact, a “feature”, and I have found that it gives it flexibility that is lacking in other situations(although, you have to put your dates in very specific formats to get the sort order to come out right…).”

“For web development purposes, if you’re doing a really high load website, you’re going to want to use a non-file based database(personally, I prefer PostgreSQL, but sub MySQL, SQL Server, whatever…)”

“I also can’t express just how great it is for desktop apps though. Its great for 95% of the situations you would need to save data in an application in a “file format” of some variety. It make debugging great(fire up the console on the file your app is writing too and watch inserts as they happen). No configuration at all. No mucking about with binary file formats. No XML parsing.”

(external quote)

I have heard many Rails users glorify the use of SQLite as a testing db… choose wisely! For me, I think I’ll stick to what my apps will probably be using as there primary production db, MySQL. :)