Subversion pre-commit hook allows to make comments required. For instance file pre-commit.tmpl contains a sample script which will reject commits if no log message is supplied, or the message is too short. However it doesn’t report back any error message (i.e. a generic “commit failed” is returned to SVN client), and there is no provision for making sure the comment is a minimum length.

Ryan Stille came up with excellent Perl script which does the job in more transparent way compare to the original shell script. It allows setting minimum length of the comment and custom error message when the message is absent or too short.

#!/usr/bin/perl
 
# config section
$minchars = 4;
$svnlook = '/usr/bin/svnlook';
 
#--------------------------------------------
$repos = $ARGV[0];
$txn = $ARGV[1];
$comment = `$svnlook log -t "$txn" "$repos"`;
chomp($comment);
 
if ( length($comment) == 0 ) {
  print STDERR "A comment is required!";
  exit(1);
  }
elsif ( length($comment) < $minchars ) {
  print STDERR "Comment must be at least $minchars characters.";
  exit(1);
  }
 
exit(0);

Note that pre-commit.tmpl has to be renamed without the “.tmpl” on it and set as executable.

Of course there is no guarantee that all comments will be relevant. But at least it could work as reminder that the comment is needed right now for current commit.

Tweet This

Tweet This

ERROR 1062 (23000): Duplicate entry ’132653-47′ for key 1

However keyword IGNORE allows to force a new unique index to drop duplicated rows.

ALTER IGNORE TABLE `t` ADD UNIQUE INDEX `i` (`f1`, `f2`);

In this case the output will be something like this:

Query OK, 507 rows affected (0.02 sec)
Records: 507 Duplicates: 0 Warnings: 0

So simply using IGNORE helps to save time on writing a custom script to clean up duplicates.

Tweet This

MySQL 5.0 to 5.1 upgrade is well documented and went pretty smoothly in our case. However our project was heavily relied on stored procedures and that gave us some troubles to deal with.

The first issue was just annoying warning “Creation context of stored routine .. is invalid” for every call of any stored routine (stored procedures and functions worked as expected).

It turned out that the upgrade to 5.1 had added four columns to the mysql.proc table:

• character_set_client,
• collation_connection,
• db_collation,
• body_utf8.

Those columns were created with a default value of NULL and that was generating the warning. But if a stored procedure/function is created in ‘native’ 5.1 environment, it has these values set to the system defaults and no warning is shown.

Manual altering the mysql.proc table and setting the value of ‘character_set_client’, ‘collation_connection’ and ‘db_collation’ to valid values prevented the error form appearing:

UPDATE proc SET
  character_set_client = 'utf8',
  collation_connection = 'utf8_general_ci',
  db_collation = 'latin1_swedish_ci';

This issue was reported as bug and marked as closed for version 5.1.21 in 2007. But it looked like it had made it back to version 5.1.4x somehow in 2010.

The second issue was more complicated and actually some stored procedures stopped working because of weird “Column count doesn’t match value count at row 1″ error (which did not make much sense though).

Additional research showed that some insert queries did not work withing prepare\execute blocks due to incompatible changes in 5.1.25 to the way that the server handles prepared statements. The bug #21774 shed some light on this issue too.

For example the statement like below (within a stored procedure) may produce the error mentioned above:

DECLARE vNum INT;
 
CREATE TABLE t (f TINYINT);
 
SET vNum = 1;
SET @sql = CONCAT('INSERT INTO t SELECT ', vNum);
 
PREPARE QUERY FROM @sql;
EXECUTE QUERY;
DEALLOCATE PREPARE QUERY;

Simply changing vNum type from INT to TINYINT helped (so the variable type matches the column type in the table).

I hope this will save couple hours to someone unless it has been taken care of in newer MySQL releases.

Tweet This

Tweet This

SHOW PROCESSLIST statement allows to see running threads (including thread ID).

Example 1:

KILL QUERY 24;

terminates the statement that the connection is currently executing under thread 24, but leaves the connection itself intact.

Example 2:

KILL 24;

or

KILL CONNECTION 24;

terminates the connection associated with the thread 24 (i.e. re-connect will be required).

Tweet This

Tweet This

A man came across three stonecutters and asked them what they were doing. The first replied, “I am making a living.” The second kept on hammering while he said, “I am doing the best job of stonecutting in the entire county.” The third looked up with a visionary gleam in his eye and said, “I am building a cathedral.”

Although these three men were doing the same job, there were three different answers. I think this is a great example of motivation “in action”.

Tweet This

Inception could be the greatest action movie with the original story for a few past years. Definitely recommended to check it out!

Tweet This

At first glance everything looked very easy:

print date('Y-m-d H:i:s.u') ;

where u is microseconds.

However it turns out PHP manual has a tiny note which states

Since this [date()] function only accepts integer timestamps the u format character is only useful when using the date_format() function with user based timestamps created with date_create().

Which means that u kind of works but in case of calling within date() function the result is always .000000.

So the straight forward solution could be something like this:

print date('Y-m-d H:i:s') . substr((string)microtime(), 1, 8);

But the drawback of the solution above is two calls to the time related functions which potentially may cause some accuracy issues.

Thus even better solution is doing just one call of time function:

list($usec, $sec) = explode(' ', microtime());
print date('Y-m-d H:i:s', $sec) . $usec;

Tweet This