Gary Edwards (Open Document Foundation) and I were talking yesterday, and he mentioned the NASCIO (National Association of State CIOs) Conference coming up. I checked out last year's conference and found an interesting set of slides from an open source session they held.

From the slides, some useful data on why state governments are buying into open source. (Note: The survey was to CIO-level IT people within state governments. Pretty credible data, especially since NASCIO gets 350-450 senior government IT folks out to its annual conference, and restricts the survey (unless I'm reading the site wrong) to the most senior IT officials).

Anyway, why are state CIOs buying into open source? Well, for one thing, because it costs less. But also because it works better:

…

In a recent blog entry I discussed some research I had done into the behavior of MySQL FEDERATED tables. Since then the question arose in the forums regarding the use of triggers with FEDERATED tables, so I performed some additional tests to see how triggers would behave.

The question was asked if triggers could be used with FEDERATED tables, and I verified that triggers could indeed be created on FEDERATED tables. With the assertion that the a trigger on a FEDERATED table did not actually fire, I set up a base table and an associated FEDERATED tables with triggers attached to both tables and verified they did in fact get called.

A 'before insert' trigger on a FEDERATED table gets called before the corresponding 'before insert' trigger on the base table, and this is rather what I would expect. If the FEDERATED table's trigger …

When using LOAD DATA especially when importing from one charset container to utf8. Make sure to issue SHOW WARNINGS after the statement. Why? Well a cryptic message might occur and lead you to the true cause of the problem.


For instance if you get a message:

"Data truncated for column 'column' at row 157"

Why was row 157 truncated? The data use to exist before correctly in the table structure in the old format, what's different?


Well, in the scenario of upgrading to true utf8 column character sets, MySQL will remove all invalid utf8 chars and produce this message. You might be lead to believe oh crap maybe I need to increase the column size, NO that's not it. In MySQL 4.1 varchar, text, chars size are no longer just a function of bytes. Previous to 4.1

varchar(255) means that it would take up to 255 bytes, i.e. 1 latin1 character 1 byte. In 4.1+ this means …

Testing the MySQL Cluster can mean a lot of typing. Not being the best typist and getting tired of typing the same thing over and over again I created a short cut to make life better.

I have a file called shortcut.sh. Inside my .bash_profile for each of my test systems, I have added this file to be run when I login.

.bash_profile example

. /home/ndb/jmiller/shortcut.sh

Then all the command and connection strings I need are just few key strokes away.

shortcut.sh

alias ndbd='/home/ndb/jmiller/builds/libexec/ndbd'

alias ndb_mgmd='/home/ndb/jmiller/builds/libexec/ndb_mgmd'

alias ndb_mgm='/home/ndb/jmiller/builds/bin/ndb_mgm'

alias mysql='/home/ndb/jmiller/builds/bin/mysql'

alias mysql_server='/etc/init.d/mysql.server'

alias ndb_restore='/home/ndb/jmiller/builds/bin/ndb_restore'

alias mysqldump='/home/ndb/jmiller/builds/bin/mysqldump'

…

With a title like "Why Google and Yahoo! can't be better open source citizens" one might think that our companies were squeezing as much as possible out of the open source world and giving little back.

But after reading Matt Assay's post a few times, I've begun to wonder how much open source code he's been publishing.

Putting aside the many contributions that Yahoo and Google have already made to various open source projects (Linux, FreeBSD, Perl, MySQL, PHP, etc.), I'd like to debunk his conclusion:

All of which means, as Tim pointed out, that these companies have failed to write code according to a cardinal open source principle: modularity. Yahoo! and Google can't open source more code because their code is too tightly bound together - layer upon layer upon layer requiring layer upon layer upon layer. This …

The utf8 spec says that a utf8 character can take up to 4 bytes, mySQL currently only supports up to 3 bytes. So, in essence if your application allowed 255 characters to be inserted into a field, when in utf8 land ie a utf8 column these 255 characters can take up to 765 bytes.

Here is a breakdown from
dev.mysql.com

• 
  
• Basic Latin letters, digits, and punctuation signs use one byte.
  
• Most European and Middle East script letters fit into a two-byte sequence: extended Latin letters (with tilde, macron, acute, grave and other accents), Cyrillic, Greek, Armenian, Hebrew, Arabic, Syriac, and others.
  
• Korean, Chinese, and Japanese ideographs use three-byte sequences.
  

While implementing the first test version of SQLbusRT, I faced a problem on how to communicate SQL requests and query results using ORTE as a medium.

Usually when doing an SQL request, a connection is set up between a client and an SQL server. The client sends its SQL request over this connection, and as an answer it receives the query results over the same channel. Unfortunately, in the bus architecture I have in mind things aren't that simple...

Remind the fact that SQLbusRT is built on top of a publish/subscribe model. Ideally speaking clients should be subscribers, and the database server should be a publisher. However, this introduces a problem for both instances:

• How does the publisher know what to publish?
• What should the subscriber subscribe to?

I already thought of a solution before I started implementing. This solution was even visible in my diagrams (see my …

Has anyone ever told you that SELECT * FROM table is bad, and did they give you a reason?
Let me give you two;

1. 
   
2. If someone were to add column level privileges and then lock you out of a column, your query will start failing.
   
3. There are certain cases where MySQL can satisfy all of your query just by reading an index. This is much faster than reading the index, then the data.
   

An example:

CREATE TABLE index_test_no_data (
 id INT NOT NULL PRIMARY KEY auto_increment,
 a char(32),
 b char(255),
 c char(255),
 d char(255),
 e char(255),
 f char(255),
 g char(255),
 h char(255),
 i char(255),
 j char(255),
 k char(255),
 l char(255),
 m char(255),
 n char(255),
 o char(255),
 p char(255),
 q char(255),
 r char(255),
 s char(255),
 t char(255),
 u char(255),
 v char(255),
 w char(255),
 x char(255),
 y char(255),
 z char(255),
empty tinyint, …

You may have read Jo's blog entry Methods to reduce the load of your webserver by caching content: using lighttpd, MySQL UDF, LUA and speed everything up. He explained there how to use lighttpd and its mod_cml together with MySQL to provide a caching system directly at the webserver, and not at the PHP level.

Now, our good ol' friend Jan Kneschke, author of god's own webserver lighttpd (called "lighty"), mentioned in his blog ("mod_cml is dead, long live mod_cml!") that the name and functionality of mod_cml is subject to change. Why? mod_cml is not about caching only, it's about deciding how to handle a request.

"Any status code can …

A