1.Turn on Apache

Go to System Settings->Sharing and turn on Web Sharing. If necessary click the button that says “Create Home Folder” which will create a folder called “Sites” in your home directory.  You now have a web server that you can access at http://localhost/~username/  (“username” being your own account login name)

2. Edit /private/etc/apache2/httpd.conf

To enable PHP uncomment (remove the number sign at the beginning of) the line:

#LoadModule php5_module libexec/apache2/libphp5.so

(optional) you can re-map the server root to your home website directory by editing DocumentRoot:

DocumentRoot “/Users/username/Sites”

If you wish to use .htaccess files then look a bit further down AllowOverride and set it to “All” like so:

Options FollowSymLinks
AllowOverride All
Order deny,allow
Deny from all

3. Edit /private/etc/apache2/users/username.conf

Your user directory has it’s own permissions as well which are located in this separate file.  You may wish to enable FollowSymLinks and AllowOverride again here by changing these two lines like so:

Options Indexes MultiViews FollowSymLinks
AllowOverride to All

4. Copy /private/etc/php.ini.default to /private/etc/php.ini

OSX includes a default php.ini file that you can use but you must rename or copy it first.  If you don’t do this then PHP will still run but it will just be using the default initialization settings with no way for you to override them.

Edit these settings in php.ini (some of these settings will not come into play until they are installed)

display_errors = On
mysql.default_socket = /tmp/mysql.sock
pdo_mysql.default_socket=/tmp/mysql.sock
date.timezone = ‘America/Chicago’
include_path = “.:/usr/lib/php/pear”

5. (Optional) Install PEAR

If you use the PEAR libraries you can install them using the included phar file like so:

sudo php /usr/lib/php/install-pear-nozlib.phar
sudo pear config-set php_ini /private/etc/php.ini
sudo pecl config-set php_ini /private/etc/php.ini
sudo pear upgrade-all

6.  Install MySQL

This doesn’t really require instructions, simply download the latest MySQL from mysql.com.  I installed the 32 bit version, however it may be possible to run the 64 bit version as well.

7. (Optional) Install Apache Plugins

If you use encryption you may need to install mcrypt.  Instructions have been provided by Michael Gracie

If you use the Zend debugger you can install that using these instructions.

Luckily there’s a solution. As an example below is a query that will set the priority to “1″ for all customers who have at least one matching purchase record. I realize this is a stupid way to run this particular query, however I am merely posting a simple example of a query to demonstrate the error and workaround. Jeez, get off my back!

A Non-Working Example:

UPDATE customer
SET customer.priority = 1
WHERE customer.id IN
(
  SELECT DISTINCT customer.id FROM customer INNER JOIN purchase ON customer.id = purchase.customer_id
)

The above query will give you the MySQL target table error because we are trying to update the customer table, but the customer table is also used to supply the list of IDs.

A Working Version of the Example Above:

UPDATE customer
SET customer.priority = 1
WHERE customer.id IN
(
  SELECT id FROM
  (
    SELECT DISTINCT customer.id FROM customer INNER JOIN purchase ON customer.id = purchase.customer_id
  ) AS tmptable
)

The query is basically the same, except the inner select is wrapped inside another select. The most important thing to note is that the original select has been given an alias “tmptable“. (The name tmptable is arbitrary, you can give it any alias name.) The alias is important because assigning one will tell MySQL to create a temporary table from this select query. The temporary table may then be used as the source criteria for the update statement.

The reason it is wrapped inside another query is because MySQL syntax does not let you assign an alias to a select query when it is part of an update statement. So we have to put it inside another query which, I suppose separates it from the update statement.

The information about creating the temporary table was borrowed from Xaprb’s blog, who goes into a little more detail about the mechanics.

I’m setting up a new machine and found a great tutorial written by Josh Lockhart on getting a PHP web development environment up and running on Snow Leopard.  This goes through almost everything to be up and running for a typical LAMP stack with unit testing using all of the default services.

Josh’s instructions include everything that I need except mcrypt & IMAP.  Luckily Michael Gracie has provided a walk-through for installing mcrypt on Snow Leopard which involves re-compiling some things, but isn’t as tough as it first appears.  A walk-through for installing IMAP support is available on activeColab (with a pre-built binary).

After getting PHP, mcrypt and IMAP going, the last step for me is setting up MySQL which has some caveats on OSX.  The main problem is that the MySQL installer places the mysql.sock file in a non-standard place and so you have to either create a link or alter your php.ini file before PHP will be able to talk to MySQL.  (If you get “Can’t connect to local MySQL server through socket ‘/var/mysql/mysql.sock’” or  “No such file or directory” when calling mysql_connect, then this is the problem)

After completing the steps on Josh’s & Michael’s pages and running the MySQL installation package, here are the additional steps that I like to take to get my local environment configured:

Edit /private/etc/php.ini

display_errors = On
mysql.default_socket = /tmp/mysql.sock
pdo_mysql.default_socket=/tmp/mysql.sock
date.timezone = ‘America/Chicago’

Edit /private/etc/apache2/httpd.conf

DocumentRoot “/Users/jason/Sites”

Edit /private/etc/apache2/users/jason.conf

Append FollowSymLinks to the Options

Change AllowOverride to All

I also like to change the permissions on php.ini and httpd.conf to allow my user account edit permissions and create an alias to those two files somewhere easy to get to.

Installing MAMP is probably easier, but for some reason I prefer using all of the services that are pre-bundled with OSX.  Also Snow Leopard includes PHP 5.3 which led me to find a couple of deprecated functions in some of our libraries.

Solution 1: Create a symbolic link

Open terminal and do the following:

sudo su
mkdir /var/mysql
ln -s /tmp/mysql.sock /var/mysql/mysql.sock

You just created a symbolic link in the place where PHP expects the socket file to be located so it should be happy.

Solution 2: Edit php.ini

If you don’t like the idea of creating a symbolic link, you can also simply alter your php.ini file to point PHP to the real location of mysql.sock.

Locate /etc/php.ini. (If php.ini doesn’t exist on your system, copy /etc/php.ini.default to /etc/php.ini).  You will likely have to do this from the terminal unless you have Finder configured to show hidden files.  Open the file and update the setting mysql.default_socket so it looks like this:

mysql.default_socket = /tmp/mysql.sock

To commit the change you need to restart Apache.  You can do that in System Settings -> Sharing, then  uncheck, then recheck Web Sharing.

There is a catch with unsigned ints however that can create problems for you if you’re not careful. That is, when you subtract unsigned ints, you will always get a positive value back no matter what. What does that mean?

Say you have a table for products with two unsigned fields: qty_in_stock and qty_sold. Lets assume for whatever reason you oversold your inventory and qty_in_stock now equals 100, but qty_sold = 101. So take the following statement:

SELECT qty_in_stock - qty_sold as qty_remaining FROM products

You would expect qty_remaining to be -1, right? Wrong! In fact MySQL returns 18446744073709551615 !

Why would this happen? Well, because MySQL is built so that when you perform a math operation on two unsigned ints, it will always return an unsigned int. And -1 is technically an out-of-bounds value for an unsigned field type. Instead of complaining, MySQL returns the value that would have represented -1 if it were unsigned which is 18446744073709551615.

Mathematically, I suppose this is correct, however it doesn’t make any logical sense to me. If anything, I think MySQL should throw an out-of-bounds error when this happens because the default behavior seems very unintuitive to me. It is as though they are trying to say that one positive value subtracted from another can never result in a negative value. Of course this is false, but that is how MySQL works.

There are two solutions to this. The first is to simply use signed ints if you ever expect them to be used in a subtraction formula. You waste some space, but it’s an easy fix.

The second solution is, if you are able to edit your SQL statement that have the subtraction, you can use the MySQL cast function. The example from above could be converted to the following:

SELECT cast(qty_in_stock - qty_sold as signed) as qty_remaining FROM products

So there is a solution to this “problem” if you will. You can read more about this subject on the MySQL site at http://dev.mysql.com/doc/refman/4.1/en/cast-functions.html

For a recent assignment we needed to populate a table that reflects seating in a stadium. The seating was typical of most venues consisting of Aisles and Seats. For example, A-1, A-2, A-3, B-1, B-2, B-3, and so on. When the table was initially populated, the seat_number field was all set at it’s default value of ’1′. So we needed sequential numbers for the seats, but the count had to start over with each new Aisle. This could have been done easily in a scripting language, but what fun is that! We wanted to accomplish the numbering in one regular SQL statement.

This problem would be easily solved using Oracle’s rownum functionwhere we can get a sequential id for each row within a resultset. But, alas, MySQL doesn’t have a rownum function. What we did find, however, is a wonderful hack on Mark Malakonov’s blog that duplicates this functionality for MySQL.

The final query, which only updates Aisle ‘A’ is here:

update venue_seat set seat_number =
(select @rownum:=@rownum+1 rownum FROM (SELECT @rownum:=0) r)
where aisle = 'A'

These fields obviously relate to a specific schema, however the @rownum trick can be used to generate sequential numbers for your tables as well. If you need to update or populate a table with sequential numbers but need some additional logic, this is a handy trick to have in your toolbox.

If you get this error while trying to create a foreign key, it can be pretty frustrating. The error about not being able to create a .frm file seems like it would be some kind of OS file permission error or something but this is not the case. This error has been reported as a bug on the MySQL developer list for ages, but it is actually just a misleading error message.

In every case this is due to something about the relationship that MySQL doesn’t like. Unfortunately it doesn’t specify what the exact issue is.

First Steps:

If you have admin permission on the server, you may want to start by running the MySQL command “SHOW INNODB STATUS” (or MySQL 5.5 “SHOW ENGINE INNODB STATUS”) immediately after receiving the error. This command displays log info and error details. (Thanks Jonathan for the tip)

If your script runs fine on one server, but gives an error when you try to run it on a different server, then there is a good chance that #6 is the problem.  Different versions of MySQL have different default charset setting and you may have unknowingly assigned different charsets on the different servers.

Known Causes:

Below is a running list of known causes that people have reported for the dreaded errno 150:

1. The two key fields type and/or size is not an exact match. For example, if one is INT(10) the key field needs to be INT(10) as well and not INT(11) or TINYINT. You may want to confirm the field size using SHOW CREATE TABLE because Query Browser will sometimes visually show just INTEGER for both INT(10) and INT(11). You should also check that one is not SIGNED and the other is UNSIGNED. They both need to be exactly the same. (More about signed vs unsigned here).
2. One of the key field that you are trying to reference does not have an index and/or is not a primary key. If one of the fields in the relationship is not a primary key, you must create an index for that field. (thanks to Venkatesh and Erichero and Terminally Incoherent for this tip)
3. The foreign key name is a duplicate of an already existing key. Check that the name of your foreign key is unique within your database. Just add a few random characters to the end of your key name to test for this. (Thanks to Niels for this tip)
4. One or both of your tables is a MyISAM table. In order to use foreign keys, the tables must both be InnoDB. (Actually, if both tables are MyISAM then you won’t get an error message – it just won’t create the key.) In Query Browser, you can specify the table type.
5. You have specified a cascade ON DELETE SET NULL, but the relevant key field is set to NOT NULL.  You can fix this by either changing your cascade or setting the field to allow NULL values. (Thanks to Sammy and J Jammin)
6. Make sure that the Charset and Collate options are the same both at the table level as well as individual field level for the key columns. (Thanks to FRR for this tip)
7. You have a default value (ie default=0) on your foreign key column (Thanks to Omar for the tip)
8. One of the fields in the relationship is part of a combination (composite) key and does not have it’s own individual index. Even though the field has an index as part of the composite key, you must create a separate index for only that key field in order to use it in a constraint. (Thanks to Alex for this tip)
9. You have a syntax error in your ALTER statement or you have mistyped one of the field names in the relationship (Thanks to Christian & Mateo for the tip)
10. The name of your foreign key exceeds the max length of 64 chars.  (Thanks to Nyleta for the tip)

The MySQL documentation includes a page explaining requirements for foreign keys. Though they don’t specifically indicate it, these are all potential causes of errno 150. If you still haven’t solved your problem you may want to check there for deeper technical explainations.

If you run into this error and find that it’s caused by something else, please leave a comment and I’ll add it to the list.

These tips are not necessarily MySQL specific, but I’m using MySQL syntax as an example for the sake of simplicity.

SIGNED vs UNSIGNED

This is probably the easiest habit to practice because you have nothing to lose and everything to gain by using SIGNED /UNSIGNED data types in the right place. There’s a simple question you can ask – will this field ever contain a negative value? If the answer is no, then you want an UNSIGNED data type.

A common mistake that I see is a primary key that is an auto-increment INT starting at zero, yet the type is SIGNED. An UNSIGNED INT can go from 0 to 4294967295 (aprox 4 billion). A SIGNED INT , on the other hand, starts at -2147483648 and goes to 2147483648 (aprox 2 billion). If you use an auto-increment starting at 0, you’ll never touch any of those negative numbers and your Id column will top out at around 2 billion.

Use a Smaller ID Data Type for Small Tables

You don’t usually know how many records your application will eventually store. You don’t want to use too small a data type in the event that your app gets popular. You might tend to use INT for your primary key column just out of habit.

In some situations, though, you do have a pretty good idea of how many records you’ll have and so you don’t need to use an INT as the primary key. For tables that contain things like permissions, system settings, account types, etc you may know that you will never need a huge number of records. You may not even create a user interface to access these tables or insert new records.

In cases like this, I find an UNSIGNED TINYINT is perfect. This will hold values from 0 to 255. Sometimes 255 is more than enough, but still gives you room to grow. You don’t want to do this if you expect to get close to this limit of course. If the data is strictly internal and there’s no user interface, the developer is usually in control of these records.

A lot of people use UNSIGNED INT as their primary key which as I mentioned earlier goes up to over 4 billion records. That is a lot of records! An UNSIGNED MEDIUMINT goes up to 16 million records which is still more than most tables need. An UNSIGNED SMALLINT goes up to 65 thousand records. You don’t want to run out of space, but you can try to optimize a bit for the best performance. Keep in mind that your primary key is the field that will be theoretically used the most for record lookups, so the more efficient you can make it the faster your app will run.

Read more about numerical datatypes on the MySQL site…

Know the Difference Between CHAR and VARCHAR

CHAR and VARCHAR both hold string/text data. However they work a little differently because CHAR is like a fixed-size array that is always the same size, where as VARCHAR will expand and contract to fit the data.

The CHAR type is useful if you have a good idea of the size that the field will be. A product code that is always 10 digits, for example, is a great candidate for a CHAR data type. The negative side of the CHAR type is that it will use up the disk space whether or not you need it. For example, if you have a CHAR(25) but your record only uses up 5 characters, MySQL will still use up all 25 on disk.

The VARCHAR is convenient because you can set it to 25, but if you only store 5 characters, the VARCHAR will only use the space it needs. Two tradeoffs for this convenience are performance and fragmentation. In particular, when you update a VARCHAR field, you might outgrow the space that was originally allocated. Your data becomes fragmented so that one record may be spread out across the DB file instead of in one nice, continuous chunk. So as time goes by, your access to the VARCHAR data will require more processing power.

MySQL provides a solution in the way of the OPTIMIZE TABLE statement. This basically will de-fragment your table VARCHAR fields. If you are using VARCHARS and doing a lot of updating, you should make sure to optimize the tables periodically. This is something that can be automated through cron or Scheduled Tasks so that you don’t forget.

In case you think it’s a simple choice, keep in mind that table size and performance are closely related. So, it follows that the VARCHAR would deliver performance benefits due to it being the smallest possible size. That would offset the performance benefit that the consistency of CHAR delivers. My rule of thumb is to use CHAR if you have a pretty good idea of the field size.

More reading is available on the MySQL site, however I find the user comments on the end of this page more interesting than the official documentation.

Don’t mix “SELECT * FROM” with TEXT/BLOB fields

TEXT and BLOB fields are extremently useful for storing large datatypes. File uploads, XML data, long text content, etc usually require one of these types of fields. Unfortunately, these fields can make a table grow large quickly. Storing binary file data for example can make a DB table enormous.

Depending on your application, this may just be the best way to store this type of data. However, if you don’t need this data on every query, then don’t select it. Here’s an example:

select * from file_upload where fu_owner_id = ’1′

What we’re doing here is grabbing the full row contents for the file uploads, though we may not need all of that data. You can imagine that this query might select all of the files that have been uploaded by a specific user for us to show in a datagrid, dropdown list or whatever. The issue here is that you rarely need to have the *contents* of the files when you are displaying them in a list. If possible, this might be better:

select fu_id, fu_name from file_upload where fu_owner_id = ’1′

In this case we have the primary key (fu_id) and the file name (fu_name). We can show this in the list Now, if the user wants to download or see the contents of the file, you can grab it using the primary key:

select fu_name, fu_data from file_upload where fu_id = ’55′

An alternative approach is to use a dedicated table with only a primary key and the BLOB/TEXT field. Any other tables that need to store large values can simply have a reference to that table’s primary key instead. If you only do lookups from the dedicated table by it’s primary key, then you’ll avoid any full table scans.

Read The Fine Manual

The MySQL site has plenty of information describing the various data types. The little bit of time and effort that you put into tuning your database will pay off as your application grows.

More reading on MySQL 5 data types can be found here: http://dev.mysql.com/doc/refman/5.0/en/data-types.html

A workaround for this is that you can configure MySQL to use the old password format for a specific account. You do that with the following SQL command:

[code:1:cb08e73675]
SET PASSWORD FOR 'some_user'@'some_host' = OLD_PASSWORD('newpwd');
[/code:1:cb08e73675]

(Obviously use your own username/password.) This will instruct MySQL to use the older password format for the specified account. Once you do this, clients that don't support the new password format will be able to login using this account.

More information can be found at [url]http://dev.mysql.com/doc/mysql/en/common-errors.html[/url]