In an effort to speed up my database updates, I've been looking for ways to batch some of my updates. CASE seems like the way to go:

mysql> create table bar(a tinyint, b tinyint);
Query OK, 0 rows affected (0.02 sec)

mysql> insert into bar(a) values(1), (2), (3), (4), (5);
Query OK, 5 rows affected (0.00 sec)
Records: 5  Duplicates: 0  Warnings: 0

mysql> select * from bar;
+------+------+
| a    | b    |
+------+------+
|    1 | NULL | 
|    2 | NULL | 
|    3 | NULL | 
|    4 | NULL | 
|    5 | NULL | 
+------+------+
5 rows in set (0.00 sec)

mysql> update bar set b = case a
    ->   when 1 then 42
    ->   when 2 then 43
    ->   when 3 then 44
    ->   else 45
    ->   end;
Query OK, 5 rows affected (0.00 sec)
Rows matched: 5  Changed: 5  Warnings: 0

mysql> select * from bar;
+------+------+
| a    | b    |
+------+------+
|    1 |   42 | 
|    2 |   43 | 
|    3 |   44 | 
|    4 |   45 | 
|    5 | …

GlassFish and MySQL bundle was released a while ago and I finally got a chance to try it out. Here are simple instructions to get you started:

1. Download GlassFish and MySQL co-bundle zip from here.
2. Install the bundle (detailed docs)
   1. Create a temp directory and unzip the contents of bundle there. The contents are:
      
      

      -rw-r--r--   1 arungupta  arungupta   239703 Mar 19 02:57 3RD-PARTY-LICENSE.txt …

I'm sitting in the back of the training room in Brisbane, following Sebastian Bergmann on the first day of his Quality Assurance in PHP Projects workshop. He is of course the right man for that job, since he wrote PHPUnit.

I have to run off after lunch to catch my flight to Adelaide (SAGE-AU 2008 Conference), where I'll be doing a tutorial on MySQL Backup and Replication strategies, and a session on managing e-mail and task overload ;-)

Here are three short routines that raise tough questions. I’ll bet that many MySQL stored-procedures experts will fail to answer all three.

Question 1. The Ambiguous Identifier

Given one table and one stored procedure:
DELIMITER //
CREATE TABLE t (x INT)//
INSERT INTO t VALUES (1)//
CREATE PROCEDURE p ()
BEGIN
DECLARE x INT DEFAULT 2;
SELECT x FROM t;
END//
CALL p()//
Notice that x is both a column and a variable.
MySQL will return
(a) ‘1′ because that’s the value of column x.
(b) ‘2′ because that’s the value of variable x.
(c) an error message because x is ambiguous.
?

Question 2. The same-level handler

Given one table and one stored procedure:
DELIMITER //
SET @@sql_mode=”//
CREATE TABLE t (x SMALLINT)//
CREATE PROCEDURE p ()
…

I was just reading Sheeri’s post Why You Want to Switch to MySQL 5.1, and my favorite 5.1 feature jumped out at me.

Online, table-based logging.

It doesn’t get a lot of press, which is sad, because it’s hella useful. I can’t tell you how many times I’ve showed up to a client’s site to help with performance tuning, started with “well, let’s look at the slow log” and (as I’m sure we all know) been foiled by the fact that they don’t have it on and can’t do a server restart. I was even at a client a couple of weeks ago where they were actually using the CSV engine support of this… although I’d never really found that all that interesting myself.

Online logging. It’ll make all the ($gender_of_sexual_preference) love you!

…

IT WORKS!!!

And not a moment too soon.
I've finished my day job for the summer and have been pouring over the code the last few days trying to isolate the last two bugs.
I've also received word that I don't have 8 days left, I have 1...so I'm a bit rushed but still hopeful.

As part of my bug fixing for the hit code (which works beautifully now) I was able to remove all of the unnecessary mutex locking from within the cache. This is a nice speed boost as there is no longer any need to lock and unlock when working with the cache. It just works (tm).

I have a fairly rough implementation of the invalidate code that looks something like this:

if(anything changed) {
nuke_the_cache();
}

It works, and it allows for multiple instances to use the same cache.
My next task is to make this a bit more refined (per table invalidation) by using …

In two words: online operations. In a paragraph: Forget partitioning, row-based replication and events. The big reasons most people are going to salivate over 5.1, and probably start plans to upgrade now, are the online operations:

• online ALTER TABLE for column rename, column default value change, and adding values to the end of an ENUM/SET
• Online, table-based logging. No more need to restart your server to enable or change the general or slow query logs. You can have the standard file-based output or choose a table format…which you can query.

(more…)

I have changed the scripts a bit.

Now everything is "self-contained" within the package so no directories outside mysqlcluster-63 is created.

You can now install this as any user! Before you needed to be root, but this is no longer needed! However, you should avoid installing it on an NFS mounted volume.

There is also a README that describes the directory and file structure and how to get going.

Quite commonly in the applications you would need to use some kind of "status" field - status of order - "new", "confirmed", "in production", "shipped" status of job, message etc. People use variety of ways to handle them often without giving enough thought to the choice which can cause problems later.

Perhaps worst, though quite common thing is to define such field as VARCHAR(255) . Even though the stored value is often short the full specified length can be used for internal processing, such as when creating temporary table or sorting.

Before we go to the list of variants which can be used lets talk about two important types of these status fields. First is BOOLEAN or YES/NO type. You would frequently see it as columns VISIBLE, DELETED , CAN_ACCESS etc. In case things are as easy as YES/NO using TINYINT UNSIGNED NOT NULL is quite a good idea, …