I hope readers will forgive yet another fleeting entry from me. My Internet connection has been unusually unreliable for about six weeks and since Monday it has been disconnecting around ten times a day. Eugh.
In other news, I’ve been using CakePHP recently. So far I’m finding it pretty good. It’s all starting to come together, but the somewhat distributed documentation makes Google my best friend for development right now! I’m finding some useful little bits as I go, so I thought I’d share things as I discover them.
Setting up the new console in CakePHP 1.2
I found it easy enough to set up the console. One of the first things I did was watch some of the screencasts, including one on setting up the terminal to run console shells from the command line. No problem. But…
Problems connecting to the datasource
I hit a bit of a problem when I wanted to play with the Access Control List (ACL) component. The console couldn’t access the database when I tried to set up the database tables:
cake acl initdb
It had the correct details from the database config file, but it just wouldn’t connect. Specifically, I was getting this
Can't connect to local MySQL server through socket '/etc/mysql.sock'
Grr. The website connected to the database fine when browsing. Hmmm. MySQL seemed to be behaving. Double hmmm. I began thinking it must be a permissions issue somewhere.
Nope, it turns out that localhost hadn’t been resolving to my local IP address. Putting in the IP (127.0.0.1) as the database host fixed everything. I’m guessing that command line PHP, or at least my installation of it, doesn’t do name lookups.
Huge thanks to the lovely and wonderful lornajane for helping me track down the problem. This saved me for some additional pain on what has already been a painful week! If this little nugget helps you too, feel free to comment and say thanks to Lorna with me!
2 Responses to “CakePHP 1.2: config for the console”
It’s probably not that “localhost” doesn’t resolve to “127.0.0.1”, but a special nuance about the mysql client. When you tell it to connect to “localhost” explicitly, it tries to connect through a socket – that is, a special kind of file which facilitates inter-process communication. Sockets are particularly useful because if the two processes are remote, then they’ll be connected via a network connection, but if they are both on the same machine then they’ll likely be communicating through a much faster means (shared memory or something similar). X11 uses this kind of communication, so that if the client and the server are on the same machine (which is normal for a desktop), there’s virtually no extra overhead with them being 2 different programs, whilst still allowing them to be on different machines if needs be.
Back to MySQL; if you specify “localhost”, then MySQL uses a socket to connect. This is fine, as long as it knows where the socket file is. The problem is that different distros tend to put this socket file in different places, and you need the client and the server to be referring to the same socket file. Sometimes this goes wrong.
You can force MySQL to use a network connection by specifying “127.0.0.1” as the server – this is still blazingly fast, and never actually hits any physical network hardware, as it should only get a small way into the kernel before it realises that the network traffic is actually for this machine. You shouldn’t really see any extra overhead with using “127.0.0.1” as opposed to “localhost”, so it’s ok really.
Hope this helps – I’m not really an expert in this stuff, so take all this with a pinch of salt (and I’m happy to be corrected by people more knowledgeable than myself…)
Thanks for the info, magicmonkey. When I got the socket error, I checked its location, which was at /etc/mysql.sock, so it should have been fine. Now I look at it again, mysql.sock is in /tmp. I think I managed to do something screwy with my config!
Anyway, I just found it weird that localhost was working on my local dev copy of the site, but running php from the command line couldn’t find it. I guess mysql.sock wasn’t being used one way, but was when running from the command line.