I just got a question from Dirk Bonenkamp. He has a query which returns a number of contacts, but he wants to get no more than 5 contacts of per customer. After thinking really hard, I came up with a solution using variables and a subquery.

To test this idea, I used the ‘world’ database available at MySQL dev zone. This query selects no more than 5 countries per continent.

SET @a=0; SET @b="";
SELECT Name, Continent FROM (SELECT @a:=IF(@b=Continent, @a+1, 0) AS a, Name, @b:=Continent AS Continent FROM Country ORDER BY Continent) AS t WHERE a < 5;

This isn't one of the nicest looking solutions, but it works. Do you have a better solution? Please let me know :).

Warning the following post has very little to do with MySQL and has a good chance of ?ranting?.

Now some of you don't know this, but I live in Beijing, China. I originally came here to study 1 semester of Chinese and stayed. At some point, I wanted to try my luck in the job market and I found one working with a European company that has an office in Beijing.


Foreigners in Beijing

Foreigners in Beijing are treated very differently, especially when it comes to salaries. Foreigners can get paid 2-3 times the amount the local people get. This is mainly because (and there are still on going arguments about this) of the exchange rate. Chinese currency is lower then US dollar or Euro so when you arrive here, your money is worth a lot more. Also, things here (depends of course if you goto the markets to get ripped off) don't cost as much as in America or Europe, including rent.
The salaries that …

A few times now, I've been wanting to write this down. I know: a lot of people will go *shrug*. Others may find me pedantic. Some of will say I'm being a smart-ass. Whatever...but I just got to write down a few of these common misconceptions that keep floating around.

None of these misconceptions are really harmful - in most cases, they do not lead to misunderstanding or miscommunication. However, when you are writing about these subjects, you'll often find that a sloppy definition you used in some place will bite you in the tail, and make it harder to explain something later on. So, that is why I from time to time get kind of obsessed with finding just the right words.

I'm not pretending I have the right words though. But there are a few informal ways of saying things that at a glance look right but are in fact wrong. Here's a random list of some of them:

PRIMARY …

New:

• Updated NDB Compressed LCP and BACKUP patches (now with O_DIRECT support)
• InnoDB patch for Windows that should give ~5x improvement on commits/sec (Bug31876)
• Everything in current telco-6.3 tree (ndb ~6.3.5)
  • Lots of NDB improvements and new features over regular 5.1.
    • • WL3686 Remove read before update
      • WL2680 NDB Batched Update
      • WL2679 NDB Batched Delete
      • WL4108 NDB Handler statistics
      • WL4096 NDB Realtime performance and settings
      • WL3126 and WL3127 Client and Replication bind address
      • NDB Online ALTER TABLE ADD COLUMN
      • NDB Multi-Master replication conflict resolution …

I?ve recently done a quick scalability test with MySQL 5.0 and 5.1 to check the new auto-inc patch with InnoDB and to see how MySQL 5.1 scales with InnoDB:

New in MySQL 5.1: innodb_autoinc_lock_mode = 1 (?consecutive? lock mode)
With this lock mode, ?simple inserts? (only) use a new locking model where a light-weight mutex is used during the allocation of auto-increment values, and no AUTO-INC table-level lock is used, unless an AUTO-INC lock is held by another transaction. If another transaction does hold an AUTO-INC lock, a ?simple insert? waits for the AUTO-INC lock, as if it too were a ?bulk insert.?
http://dev.mysql.com/doc/refman/5.1/en/innodb-auto-increment-handling.html#innodb-auto-increment-configurable
This fixes the …

Today I attended to first MySQL AB conference in Milan (Italy). They have presented the new services and the new italian team.

It was also the occasion to meet some friend.

Well MySQL AB, enjoy your business in Italy.

The 1.5.2 release of innotop contained two bugs, one very minor. The other was a crash because of the new functionality that aggregates results across many connections. I fixed them and released version 1.6.0, which I consider stable and ready for everyone to use. (My version naming convention for innotop is that even-numbered minor versions are for production use; odd-numbered, such as 1.5.2, are the development branch. That’s why I release them under the innotop-devel package).

I created MySQL Table Checksum because I was certain replication slaves were slowly drifting out of sync with their masters, and there was no way to prove it. Once I could prove it, I was able to show that replication gets out of sync for lots of people, lots of times. (If you really want to hear war stories, you should probably talk to one of the MySQL support staff or consulting team members; I'm sure they see this a lot more than I do).

I finally figured out what was causing one of my most persistent and annoying out-of-sync scenarios. It turns out to be nothing earth-shaking; it's just an easy-to-overlook limitation of statement-based replication. You could call it a bug, but as far as I can see, there's no way to fix it with statement-based replication. (I'd love to be proven wrong). Read on for the details.

One of the biggest complaints I’ve had with HTML_QuickForm is not producing valid XHTML Strict code. Well there is a simple solution to removing the name attribute of the HTML form element tag using remoteAttribute().

Example
$form->removeAttribute(’name’);

ShareThis

Thinking I had something new, I wrote this article about recovering deleted files. However, it turns out Frits Hoogland had already blogged about recovery of deleted files on linux, as Frits pointed out in a comment on my blog, where he also mentioned a metalink note on this matter. The note ID is: 444749.1 “Retrieve deleted [...]