MySQL by default is vary lax with data validation. Silent conversions is a concept that is not a common practice in other databases. In MySQL, instead of throwing an error, a warning was thrown and many applications simply did not handle warnings. With the introduction of sql_mode=STRICT_ALL_TABLES (or TRADITIONAL), in MySQL 5, a better level of validation now exists.

My understanding was that Warnings are now thrown as Errors, therefore eliminating the need to do a SHOW WARNINGS to confirm any problems after every query (this is a performance overhead on a high volume system due to the round trip latency).

However I found an instance where MySQL in STRICT Mode still throws warnings, leading to the question, are there any other areas, and does the earlier statement “Warnings are now thrown as Errors” hold true.

Here is my seeding process to showing the problem.

mysql> create table i(i tinyint, unique key( …

Sun has launched the Glassfish Portfolio,  the best web application platform on the planet.

To learn more, you can also go to "the Aquarium" and "Miles to go...."

The current size of a MySQL 5.1.30 installation is around 420M.

$ du -sh .
426M    .

A further breakdown.

$ du -sh *
213M    bin
20K     COPYING
9.8M    docs
8.0K    EXCEPTIONS-CLIENT
436K    include
12K     INSTALL-BINARY
121M    lib
504K    man
4.0K    my.cnf
77M     mysql-test
4.0K    README
20K     scripts
2.3M    share
2.9M    sql-bench
100K    support-files

A means to reduce the footprint by 25% is to delete some unused stuff.

$ rm -rf docs/ mysql-test/ sql-bench/
$ du -sh .
337M    .

It’s no big deal, however it certainly does cut down on verbose output in the backup logs removing the mysql-test directory and files.

Sun has launched the Glassfish Portfolio,  the best web application platform on the planet.

To learn more, you can also go to "the Aquarium" and "Miles to go...."

Sun has launched the Glassfish Portfolio,  the best web application platform on the planet.

To learn more, you can also go to "the Aquarium" and "Miles to go...."

I’m speaking at the User Conference this year, with a half-day tutorial and three further sessions. The running theme is performance, both in terms of the performance of your queries, and in terms of scaling up.

Scale Up, Scale Out, and High Availability: Solutions and Combinations

This is the big tutorial. It’s difficult to resolve what I’ll be talking about into a few sentences, but think about all of the different technologies available here - replication, partitions, sharding, DRBD, memcached - I’ll be talking about all of them, and more importantly combinations of the different solutions and where the potential performance gains and pitfalls are. I’ll also be using the opportunity to demonstrate some of the more obscure combinations that you can use to provide the environment you need.

…

DTrace has been something that I’ve been trying to get into the MySQL server for more than a year now.

After a combination of my own patches and working with Mikael Ronstrom and Alexey Kopytov we finally have a suite of probes in MySQL 6.0.8. Better still, after a short hiatus while I was busy working on a million-and-one other things, the documentation for those probes is now available: Tracing mysqld with DTrace.

The documentation is comparatively light and deep all at the same time. It’s lightweight from the perspective that I’ve added very little detail on the mechanics of DTrace itself, since there is no need to replicate the excellent guides that Sun already provide on the topic. At the same time, I’ve tried to provide at least one (and sometimes two) D script examples for each of the groups of probes in the 6.0.8 release.

Few days ago we were chatting in our corporate Campfire room and one of the guys asked me what do I think about Rails developers hiring process, what questions I’d ask a candidate, etc… This question started really long and interesting discussion and I’d like to share my thoughts on this question in this post.

So, first of all I would like to explain what kind of interviews I really hate Ever since I was thinking of myself as of a developer (many years ago) and was going to “software developer position” interviews I really hated questions like “What is the name and possible values of the third parameter of the function some_freakin_weird_func() from some_weird.h” or “How to declare a virtual destructor and when it could be useful?”… All my life I had pretty practical thinking and never bothered to learn APIs or some really deep language concepts that are useful in 1% of …

There are some basic, golden rules when it comes to having a vibrant community of contributors.

The following are rules I have extracted and learned based on my experience managing and working with engineers actively involved and participating in the Apache/Derby, PostgreSQL and MySQL open-source communities. These rules are also based on extensive discussions with many folks involved with the MySQL community, with the PostgreSQL community and with the Apache/Derby (Java DB) community, over many years.

Before I go through these rules, I would like to thank Marten Mickos for having suggested some of the headings for these rules. (I originally had much longer headings for all of them.) I would also like to thank many of MySQL, PostgreSQL and Java DB colleagues, as well as to many other colleagues involved in open-source development, for having contributed to the ideas and practices behind these rules.

A) …

There are some basic, golden rules when it comes to having a vibrant community of contributors.

The following are rules I have extracted and learned based on my experience managing and working with engineers actively involved and participating in the Apache/Derby, PostgreSQL and MySQL open-source communities. These rules are also based on extensive discussions with many folks involved with the MySQL community, with the PostgreSQL community and with the Apache/Derby (Java DB) community, over many years.

Before I go through these rules, I would like to thank Marten Mickos for having suggested some of the headings for these rules. (I originally had much longer headings for all of them.) I would also like to thank many of MySQL, PostgreSQL and Java DB colleagues, as well as to many other colleagues involved in open-source development, for having contributed to the ideas and practices behind these rules.

A) …