MySQL told me that it had a problem renaming a file. So I really thought I would go and help it by removing the file on the command line. But somehow I really felt that it didn’t really mean to rename a file. So I did a bit of googling and in the mysql bug tracker I found the problem.
The real problem occurs when you are using foreign key constraints with InnoDB. Even though I had only created an additional unique index on one of two columns where one of them was a foreign key. And when I tried to remove it mysql told me it had problems renaming a file :-(.
The solution was to remove the foreign key using ALTER TABLE tablename DROP FOREIGN KEY fkname. Now I was able to remove my index and then I added the foreign key constraint again.
Really ugly.

So, we (dealnews.com) rolled out a new site this month, metaprice.com.  Its young and lacking features of many of the other price comparison sites, but is has great potential.  Our hope is to bring together the best features of all the other players in the market in one great application.
Part of this project required using web services with several different data suppliers.  Most support simple REST and SOAP, but some only offer SOAP.  So, given that I bit the bullet and enabled the SOAP extension for PHP5.  Wow!  I was happily surprised.  The last SOAP code I had looked at was the old PEAR code.  It was not that attractive to me.  It required a lot of work IMO to talk SOAP.

Now, with just 3 lines of code, I can get back a nice object that has all the data I need.  Kudos to Brad …

Update: As some people have pointed out, if this is on all the time in a production environment, it could be bad. We only enable it when debugging. But, in the interest of keeping the PHP world safe, I have edited the code.

Preface: I would not use this in a production environment on a full time basis.  When we do use it, we turn it on, gather some logs and turn it off.  Also, it has been pointed out to me that this will cause MySQL to not use the query cache in versions previous to 5.0.  That is another reason to not use this in a production environment full time.

So, on dealnews.com we often end up with a lot of queries that look kind of the same. It usually because we have a complex query that simply selects article ids from one or two tables and then a second query to select the data from the article table using those ids. If you have used MySQL …

So, a while back, I did some tests with the mysql, mysqli and PDO extensions. In those tests, I found PDO to be much slower for selects than mysql and mysqli. Half as slow in fact. Santos mentioned these tests in a post about SDO. Wez has pointed out that the mysql API does not use the query cache when using prepared statements. Apparently, under the covers, PDO uses prepared statements for all queries. At least that is what I am taking from this. My tests showed the same speed whether I used the PDO prepared syntax or not.

So, I decided to try Wez’s trick of emulating prepared statements to see how PDO did. The results were interesting. Not sure if these are the “fair comparisons” that Wez wants to see, but I …

From our jobs page:

As a dealnews web developer, you will help maintain our current stable of deal and price-tracking web sites, and build new features and new web sites as we continue to grow. You’ll be part of a small, fast-moving team of developers that are involved at every stage of product development, from concept to rollout.

We use Gentoo, Apache, PHP and MySQL.   While that does not need to be your expertise, it is a plus.  We have a little Perl and Python thrown in as well.  You will need to code on a non-Windows system as we run our development environment on our local machines.  Currently, we all use Macs.

A big plus, however, is disc golf.  We play weekly as an um, team building excercise. Yeah, team …

Problem 1 in the article at IBM developerWorks kind of rub me the wrong way.

1. Using MySQL directly

Why not? How is the second code example in that post superior to the first? What I see is that the first example, that uses mysql_* directly, is more readable. The second snippet is a jumbled mess.

The article recommends using PEAR::DB. Is PEAR::DB even PHP5 ready? I don’t know, I don’t use it. The author could have at least used PDO. Still slower, but not as bad and is the future of PHP database abstraction IMO.

He uses a prepared statement to do the select. First, I have tested and I know is slower for MySQL. Second, it is not the end all be all of stopping cross site scripting that a lot of people believe it to be. You can only pass certain value parts of certain …

Today Peter Zaitsev announced launch of new forums related to MySQL Performance questions. He says:

This forum is created as free alternative to MySQL Consulting Services which we provide. If you would like to get some free help to your performance issues please use forums so everyone else could benefit from our replies. You also should get more opinions on your performance problems from other forum members. There were a lot of unrelated performance questions placed as comments and sent by email and we had to find better way to organize it.

I think that it is a great idea to start such forums ontop of great blog site because many people can find it from Google when looking for some performance related questions or discussions. So, I want to say good luck to peter and will try to participate any discussions in these forums.

At this week I came across great blog of Peter Zaitsev and Vadim Tkachenko - two developers from High Performace Group at MySQL Inc. This blog’s name is MySQL Performance Blog and, as you probably assume, it is about misscelaneous sides of MySQL optimization and related stuff. So, if you are MySQL administrator or, even, developer, that works with MySQL, I would advise you to take a look at this blog - there are lots of useful MySQL optimization info.

Tags: mysql, high, performance, …

Now that I am a happy user of PHP5 and MySQL5 and using that for writing a new application, which fortunately involves using the newest technologies, I am finally able to solve one of the biggest issues I always had had with DB-driven applications: foreign key contraints.

Constraints and transactions
I am using InnoDB (I know those contraints had been possible before MySQL5) for that and the first time I am also using the foreign key constraints InnoDB provides. And it does make me happier :-). I don’t have to take care of updating and deleting all the referenced table rows myself, the DB’s storage engine does that for me, as I always had wanted it.

I had started out using MyISAM tables and triggers, but when I realized that I am programming the application using transactions I had to switch to InnoDB …