Is there a downside to commenting out the 'socket' option of the
MySQL adapter in database.yml by default?
It's not uncommon to run the 'rails' command before the database has
been install properly or started, and wind up with a bogus socket
option set in database.yml. For example, if the MySQL server isn't
running, you end up with:
socket: /path/to/your/mysql.sock
Then when you go to run the app you get:
Can't connect to local MySQL server through socket '/path/to/your/
mysql.sock' (2)
That's a fairly easy one to diagnose. Less intuitive is if you botch
a MySQL install and end up with two active sockets where the
database.yml points at one socket by default, but you intended the
app to use the other socket.
Currently, the database.yml is generated as follows:
socket: /tmp/mysql.sock
# Connect on a TCP socket. If omitted, the adapter will connect
on the
# domain socket given by socket instead.
#host: localhost
#port: 3306
I'm proposing that it should be generated as:
# Connect on a TCP socket. If omitted, the adapter will connect
on the
# domain socket given by socket instead.
#socket: /path/to/mysql.sock
#host: localhost
#port: 3306
That is, setting a socket is the exception rather than the rule. For
most of the get-up-and-running apps I've seen, the socket isn't
necessary. Trying to set it is often an impediment to getting
started with Rails. But I suspect there may be downsides that led to
the decision to use a default socket.
Mike
_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
