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.

During the Intro to Rails portion of tonight’s Philly on Rails, a question was raised asking if there was a better way to give Rails your database password, rather then storing it in the database.yml file.

I tried the method below, which seems to work:

development:
  adapter: mysql
  database: whatever_development
  username: whatever
  password: <%= gets %>
  socket: /tmp/mysql.sock

The first time the database is accessed by Rails, you can simply enter the password at the script/server prompt and you’re in business.

However, I’m not sure how this would work with the -d option on script/server. I imagine it would not work.

Update: PragDave has some thoughts on this, too.

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. :)

NEAT!

I just discovered (thanks Google!) that you can do find/replace within strings inside a MySQL table. In this case, I had to push a website live that contained product descriptions in which the client had referenced the development site URL. So:

Worked like a charm. I was about to do a mysqldump and do something with sed and grep and then have to re-import the table. But this worked great.