If you have a great idea and want to given away the source code for free and not earn millions - now you can do it at the c’t Masup competition. You only have to write a cool application, a Mashup web app and give away the source code including SQL dumps and documentation, of course! And if you get lucky you get a free iPod video for it. Yippi … let’s start coding :-).
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 for it to have any effect at all. Transactions solve the next problem I always had, uncompleted or failed database modifications.
I upgraded my mind too and was able to drop the triggers, doh. Oh man, that was a long process, even though all this knowledge was available already in some corner of my mind.
Watch out
But I actually wanted to write down the one thing that I had been looking for for a while:
Create foreign keys only on columns with the exact same type!
Of course. Yes, of course. Makes sense, but I just wanted to have a go and try the foreign key constraint and didn’t watch out for the types, then I got the error:
ERROR 1005: Can’t create table (errno: 150)
And the manual just told me the standard things, but not this!
Won’t work
CREATE TABLE chapter (
chapter_id int(10) NOT NULL auto_increment,
title varchar(20) NOT NULL,
PRIMARY KEY (chapter_id)
) ENGINE=InnoDB;
CREATE TABLE subchapter (
subchapter_id int(11) unsigned NOT NULL auto_increment,
chapter_id int(11) unsigned NOT NULL,
title varchar(20) NOT NULL,
PRIMARY KEY (subchapter_id),
KEY chapter_id (chapter_id),
FOREIGN KEY (chapter_id) REFERENCES chapter(chapter_id)
ON UPDATE CASCADE ON DELETE CASCADE
) ENGINE=InnoDB;
The two columns chapter_id are of a different type, int(10) and int(11), and one is signed the other unsigned! Only if you get both types exactly right the creation of the foreign key constraint will be successful! Otherwise you get the meaningless error message mentioned above, which does not really help.
Will work
CREATE TABLE chapter (
chapter_id int(11) unsigned NOT NULL auto_increment,
title varchar(20) NOT NULL,
PRIMARY KEY (chapter_id)
) ENGINE=InnoDB;
CREATE TABLE subchapter (
subchapter_id int(11) unsigned NOT NULL auto_increment,
chapter_id int(11) unsigned NOT NULL,
title varchar(20) NOT NULL,
PRIMARY KEY (subchapter_id),
KEY chapter_id (chapter_id),
FOREIGN KEY (chapter_id) REFERENCES chapter(chapter_id)
ON UPDATE CASCADE ON DELETE CASCADE
) ENGINE=InnoDB;
Let’s see what’s coming after InnoDB …
Finally Pet Shop Boys will release a new album, I had just heard on the radio that it will come out in May. On petshopboys.co.uk a couple of concerts are listed but none in Munich yet it seems :-(.
Now I just got to listen to the new single I’m with stupid.
(c) Pic from petshopboys.co.uk
I am writing a heavy JavaScript application and now I can understand the advantages it had doing embedded programming :-).
The simple task I ordered my browser to process via JavaScript, was that it shows this image 
and then starts doing the real work, which will take long, so indicate that first by showing the image. Nothing easier than that, set style.display = “inline” and go for it. But to my surprise the image was never shown, may be sometimes for a very very short time at the end, when everything was already over. That lead me to investigate what really happens there. And I wrote a little script which basically does those two things in this order:
The resulting script is here.
The result I saw was that the rendering obviously does not happen in real time, as the script would let you assume. It is “put off” to a later point in time and while the heavy-load-task is executed the rendering does not take place. In my case the heavy-load-task was just looping over thousands of calls to document.getElementById, since there was no setTimeout or anything alike used in this loop I expected the browser to be busy for a while, of course. But that the showing of the image was not done until the loop had ended was a surprise to me. Imho it makes clear that the browser either updates his DOM tree very quickly but the rendering engine doesn’t get time to update the screen or that the DOM changes are put in some queue and processed later, which would be very difficult and cause race conditions easily. So I think the first thing happens. For programming reliable JavaScript, especially DHTML this knowledge is extremely valueable but the fact is very obstructive.
That strengthens that a poorly implemented JavaScript can block the browser easily (we all knew that). But now in the times of AJAX JavaScript becomes more and more a thing that is used heavily and the browsers don’t seem to be prepared for this load yet.
No browser is prepared as my tests have shown. This makes me doubt that I am just doing it right and may be I am testing something irrelevant or may be in the wrong way, but I doubt it.
I tried all the relevant browsers I have available on Mac OS X those are the times it takes them to finish the heavy-load-task and to finally show the image (or hide as in the example above).
Firefox 1.5 - about 2 seconds
Safari 2.0.3 (comes with Mac OS X 10.4.6) - at least 10 seconds
Safari nightly build (from http://nightly.webkit.org/builds) - about 0.4 seconds
Opera 8.54 - about 0.7 seconds
The heavy-load-task in the script is looking through the DOM tree and searching for 30.000 elements (you can change this number), which don’t exist. But the DOM tree is actually very small (just have a look at the source) that it is even more surprising that it takes even about 10 seconds in Safari, but fortunately the new version of Safari will be significantly faster!
And by the way, it doesn’t matter if I am looking for the same node every time in the loop or for a different node every time, I tried it (there is no caching of the nodes obviously).
Or did I just do something wrong or misunderstand something?
Sharper minds: please let me learn!
It is already a lot of years ago, that I was in the United States as an exchange student and going to highschool and later college (TSJC) but the later was just two weeks, which I enjoyed very much nevertheless. And since then I was always trying to kind of look around the area where I used to be and now I found city-data.com, which has very many infos and even some pics of Garden City, Kansas and Trinidad, Colorado. Quite interesting …
This page is devoted to various tips and tricks that help improve the performance of your Python programs. Note: You should always test these tips with your application and the version of Python you intend to use and not just blindly accept that one method is faster than another.
I have found a very nice mod_rewrite tutorial, it is a little less geeky and ‘jucier’ than the official Apache URL Rewriting Guide.
In case you every forget how to create a virtual host on a Mac OS X (like I did), this article just reminded me how.
My PHP5 and PDO (PHP Data Objects) experience is very young (to be exact: one day), but I have already learned an important lesson, which is rather a mysql lesson, than PDO, I guess.
PDO default is unbuffered query
I had the simple code:
$dbh = new PDO(’mysql:host=localhost;dbname=test’, ‘root’, ”);
$dbh->prepare(’SELECT * FROM test WHERE test_id=?’);
$dbh->execute(array(1));
$dbh->fetchColumn(0);
$dbh->prepare(’SELECT * FROM test1 WHERE test1_id=?’);
$dbh->execute(array(2));
It always gave me a “Call to a member function execute() on a non-object” in the line of the last execute(). I was really speechless. I even tried to create a new PDO object every time, that seg-faulted on me. It wasn’t the right thing to do anyway, so that was ok.
With Johann’s help we found out that the unbuffered query is the problem. I didn’t retreive the complete result set (I only do a fetchColumn()), so there is still an open result set on the server. And a new execute() is awry. Calling a fetchAll() after the fetchColumn() helps, but is not what you want to do. The solution is to use buffered queries, create the new PDO object with the attribute PDO::MYSQL_ATTR_USE_BUFFERED_QUERY set to true, like so:
$dbh = new PDO(’mysql:host=localhost;dbname=test’, ‘root’, ”
,array(PDO::MYSQL_ATTR_USE_BUFFERED_QUERY => true));
Ilia already mentioned this problem last year. Anyway it still seems to be a point that needs to be stated clearer in the docs. I am happy I learned something. That’s not bad for one day PHP5 and PDO.
Why not Python?
If you followed this blog and are wondering how come that I am doing PHP again, well it is the simplest to get running. I would love to do it in Python, but getting set and started simply takes much more time, and I just want to get a prototype out the door. I am also much more familiar using PHP and my latest experience with the EXIF stuff for Python doesn’t make me very optimistic, that Python is easy enough to use for all the web tasks I expect to do.
I am sure that if I did about a month of this stuff in Python I will have understood it all too, but I don’t have this time now, unfortunately. But at least I have the plan to redo it all in Python (btw. I have many plans).
The new version 2 of the Maps API had been announced today. The reduction of the code size to the half of the code size of version 1 sounds promising. Still I guess my requested loaded-event is not implemented, at least not that I know of.