For a recent Rails project, I had to use PostgreSQL instead of the standard MySQL for the database. Setting up Postgres on Mac OS 10.5 has some quirks, which I will share with you here.
- There are three primary ways to get PostGRES onto Leopard: a pre-built binary, MacPorts, and source. My choice was to build with source. There are several good posts on building from source:
I do not recommend creating a separate user to run postgres. Doing so clutters your startup screen with another user, and requires you to su to that user to start the database. Instead:
1) install Postgres as root
2) after install, from the command line: chown -R andre /usr/local/pgsql/data. The -r flag changes the ownership recursively. Obviously, substitute your own username for "andre" in the example.
Since I don't use PostGres all the time, I don't want it to be started up automatically. Instead, I set up two aliases in by .bashrc:
alias startpostgres='/usr/local/pgsql/bin/pgctl -D /usr/local/pgsql/data -l /usr/local/pgsql/data/logfile start' alias stoppostgres='/usr/local/pgsql/bin/pgctl -D /usr/local/pgsql/data -l /usr/local/pgsql/data/logfile stop'
when you start postgres, you'll probably get the dreaded "shared memory error," which looks like this:
FATAL: could not create shared memory segment: Cannot allocate memory DETAIL: Failed system call was shmget(key=1, size=1081344, 03600). HINT: This error usually means that PostgreSQL's request for a shared memory segment exceeded available memory or swap space. To reduce the request size (currently 1081344 bytes), reduce PostgreSQL's sharedbuffers parameter (currently 50) and/or its maxconnections parameter (currently 10).
some resources will tell you to edit the /etc/rc file, which is incorrect for Leopard. Instead, create
/etc/sysctl.conf(if it does not already exist -- mine didn't), and add the following lines:
kern.sysv.shmmax=167772160 kern.sysv.shmmin=1 kern.sysv.shmmni=32 kern.sysv.shmseg=8 kern.sysv.shmall=65536
You'll need to su to root to create
Have fun with Postgres!
I have a geocoding recipe coming out in Pragmatic's Advanced Rails Recipes. The recipe is titled "Finding Things by Location," and it offers how-tos and best practices on using my GeoKit plugin to, well, Find Things by Location. The most recent PDF of the beta book includes my recipe along with over 30 other recipes by community leaders like Chris Wanstrath, Dan Benjamin, and Geoffrey Grosenbach, to name just a few.
Say what? You import your fixtures with rake db:fixtures:load FIXTURES=neighborhoods,shops right? Yes, but there's a crucial difference:
- The standard rake fixtures:load does a straight data load into the database -- your Rails Models are not involved. It's as if you did a series of INSERT INTOs through your MySQL command line.
- The instantiation script takes the fixture data, and invokes the associated model's constructor for each item.
Why the lookup web service? The Google Maps API doesn't just let you map an address. You need to supply the Maps API with a longitude and latitude to place a marker on a map (or even to center a map on a city). The geocoding web service translates a valid address into longitude and latitude; you can pass the result to the Maps API.