Came across by accidence:
http://en.wikipedia.org/wiki/Conway's_Law

"Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations."

ooooops .. I posted this in the 'MySQL' category.
... anyway let it stand as a commentary to the turmoil about MySQL 'crippleware' and the obvious (FEDERATED) mistake in the 5.1.24 release.


btw: I like this interpretation:
"In every organization there is one person who knows exactly what is going on at all times. This person must be fired."

According to my local newspaper British scientists have proved that the pre-historical Neanderthal human was not able to speak wovels very well.

So now we know the origins of Dutch!

What a wonderful absurd phrase - 'pending general availability'!


When I saw this:
http://www.mysql.com/news-and-events/press...se_2008_14.html

.. I thought it meant the MySQL 5.1 would be GA very shortly. So when I saw 5.1.24 on FTP mirrors only few hours later, I thought it was the one. This resulted in this bug report: http://bugs.mysql.com/bug.php?id=36132


So now I understand that 'pending general availability' means that *some day* it will come. What I think everybody realized ever since 5.1.1 alpha was released! I would hereby like to announce the 'pending general availability' of my funeral ...


It is so nice when people are able to keep quiet when they have nothing to say! UC or not - such press releases are polution!

I recently reported three bugs to MySQL that show that specifications with the MySQL server are rather 'loose' - either spec's are not very exact or they are not honoured by developers. The reports are

http://bugs.mysql.com/?id=35863
http://bugs.mysql.com/?id=35902
http://bugs.mysql.com/?id=35924


Everything seems to be very 'loose' here. It does not really seem to matter if we use 'quotes' or `backticks` - or nothing. Docs (what must also be considered as Specs as no formal Specs are there) clearly state that ONLY format 'user'@'host' is allowed, but me@`%`, me@localhost and `me`@`localhost `will work in some contexts. Also the term 'identifier' is not exact for alias'es - it may be a quoted string, but not for identifiers of other types.

Another (similar, known, old and annoying) issue was reported recently by a MySQL employee: server variables randomly use either hyphen or underscore. It seems completely random and dependant on the 'taste' and 'feelings' of individual developers.


For most users this is probably not a problem, but when coding general client applications for MySQL (as we are doing with SQLyog and MONyog) this is all very annoying. Also because it sometimes does not seem to matter much if we change a little from time to time!

We need predictable output from SHOW statements and from queries to Information_Schema.



So will you please 'Tighten Up And Fly Right'! Get SQLyog Enterprise and Monyog with 20% UC discount off!
Start here: http://www.webyog.com/en/buy.php and just enter "conf08" as the Coupon Code during your purchase.

And also do not forget to visit our booth #419 at the UC.

SQLyog 6.51 has been released.


Major features added in the 6.5 tree are:
* Schema Designer zooming, printing, and 'save as graphics'.
* Speed improvements
* Transaction support
* Full support for EVENTs
* Autocompletion extended to support alias'es (currently table alias'es - column alias'es to be added in 1-2 weeks)
* Redesign of Copy & Export dialogs for complete control on object selection
* Backup of 'all data' and 'all user data' in one operation

Refer to changelogs at http://webyog.com/faq/content/33/7/en/sqly...on-history.html for full details.


About the Schema Designer:
The SQLyog Schema Designer is a graphical implementation of direct client functionalities. It works directly against the MySQL database it is connected to and uses no 'model' internal for the program. There is no need to 'reverse engineer' or 'forward engineer' when using SQLyog Schema Designer. A saved 'layout' (not 'model') has information about how to display objects on the Schema Desingner 'canvas'. Further is has what information is required to validate that the 'layout' and the underlying database are 'in sync'. Except for that we do not duplicate any information that is stored in the database. Due to this design we don't need a SQL parser in the program. It also would never be as accurate as the server itself. With the SQLyog Schema Designer every change is validated directly against the server at once. Also this design makes the use of the Schema Desinger very flexible: You can have a 'layout' that is complete for a database of course, but it is equally possible to have a layout describing only a subset of a database (and you may have more – and even 'overlapping' – layouts for every database).

The Schema Desinger is the lastest distinctive SQLyog Enterprise features added - in addition to advanced connectivity options (HTTP-tunnelling, SHH tunnelling), Migration from other RDBMS, structure and data synchronisation, advanced backup tool, Scheduled Query execution and notification, Query Builder and Autocompletion.


... and BTW: also MONyog was updated from 2.0 to 2.01 recently.


Downloads: http://webyog.com/en/downloads.php
Purchase: http://webyog.com/en/buy.php

MONyog 2.0 FINAL was released last week.


I have already posted when first beta was released and I'll repeat the two most obvious improvements:


* SSH-tunneling to MySQL servers. The implementation does (unlike current SQLyog implementation) not start any external process. The performance for this 'home grown' SSH-tunnel wrapper is very high (you may find it faster than direct connection to MySQL on a remote host)!


* Analysis of historical data (trends). You can select whatever time interval you want for the analysis. Counters that are UPTIME based (or if you like: CUMULATIVE counters as opposed to SNAPSHOT counters) can be aggregated using SUM function and common time intervals (HOUR, DAY, MONTH etc.). This is semantically similar to the query "SELECT SUM(<counter>) .. GROUP BY <time interval>" (but the real query behind this interface is much more complex of course!). This history/trends analysis is a 'probe' actually for the initial design of the embedded database used by MONyog. It came out as expected.

We have already had requests (of course) to support GROUPED display counters for non-UPTIME/SNAPSHOT counters, as well as supporting other aggregates than SUM (AVERAGE and MAX would make sense too in lots of situations). With this release the CPU counter will display with the AVERAGE function for the GROUP interval. Before implementing for others we wil have to analyze and decide on the GUI interface as well as the Javascript interface for each type of counter. There are some pitfalls and it is very easy to display lots of numbers and metrics that the user does not have a change to understand the meaning of - and even some that just do not make much sense at all. We will take the time we need to analyze in depth. But it is in progress.


* Also the graphics 'looks and feel' and the documentation is now vastly improved.
See screenshots: http://www.webyog.com/en/screenshots_monyog.php


* Additionally with this release we have started releasing 64 bit binaries for Linux and solved an issue that prevented installation on some older Linux distros (including RHEL3). We also managed to 'push in' some Dashboard configuration enhancements that were not originally planned for this release. This is new as compared to the beta's.



It was nice finally to have it out. It was also 'high time' because the log analysis component is almost finished and ready to be merged into the main code trunk. First beta with that addition representing next step in MONyog development can be expected very soon.



Purchase: http://webyog.com/en/buy.php
Downloads: http://www.webyog.com/en/downloads.php

Now - what will you get from this:


delimiter |
select 1; |
delimiter ;
select 1| ;



Find the answer here: http://bugs.mysql.com/bug.php?id=35408

I wonder if Carsten could find some rarely read 'corner' of the MySQL docs that would make it possible for him to include it in his 'Pop Quiz'.

(Don't mistake .. I love Carsten's Pop Quiz'es .. it reminds me everytime that I am not supposed to understand the World fully - at least not the MySQL part of it! )

SQLyog 6.5 beta1 has been released.


With this release we have implemented Schema Designer zooming, printing, and 'save as graphics'. Those features were 'promoted' due to overwhelming request for this when 6.1 was released. Still we have been able to improve the program in several other aspects as well with this release.

But first I must pass an apology to those people that commented on my blog post describing the Schema Designer when version 6.1 was released (with the first version of the Schema Designer). I deleted the complete post by mistake when I was cleaning up spam posts in our blog system. So I will just summarize here what I wrote at that time:

The SQLyog Schema Designer is a graphical implementation of direct client functionalities. It works directly against the MySQL database it is connected to and uses no 'model' internal for the program. There is no need to 'reverse engineer' or 'forward engineer'. A saved 'layout' (not 'model') has information about how to display objects on the Schema Desingner 'canvas'. Further is has what information is required to validate that the 'layout' and the underlying database are 'in sync'. Except for that we do not duplicate any information that is stored in the database. Due to this design we don't need a SQL parser in the program. It also would never be as accurate as the server itself. With the SQLyog Schema Designer every change is validated directly against the server at once. Also this design makes the use of the Schema Desinger very flexible: You can have a 'layout' that is complete for a database of course, but it is equally possible to have a layout describing only a subset of a database (and you may have more – and even 'overlapping' – layouts for every database).

The major improvement with this version (in addition to the Schema Designer enhancements) are:

* 10x speed improvements in many batch/bulk operations
* Improved Auto-complete with Alias support
* Redesign of Copy & Export dialogs for complete control on object selection
* Transaction support in background/batch tasks
* Full support for EVENTS

More details:
http://www.webyog.com/forums//index.php?showtopic=3831


Enjoy! - and do not forget to check out Monyog 2.0 beta 2 too!

MONyog 2.0 (beta) was released last week. It adds:


* SSH-tunneling to MySQL servers. The implementation does (unlike current SQLyog implementation) not start any external process. The performance for this 'home grown' SSH-tunnel wrapper is very high (you may find it faster than direct connection to MySQL on a remote host)!

* Analysis of historical data (trends). You can select whatever time interval you want for the analysis. Counters that are UPTIME based (or if you like: CUMULATIVE counters as opposed to SNAPSHOT counters) can be aggregated using SUM function and common time intervals (HOUR, DAY, MONTH etc.). This is semantically similar to the query "SELECT SUM(<counter>) .. GROUP BY <time interval>" (but the real query behind this interface is much more complex of course!). This history/trends analysis is a 'probe' actually for the initial design of the embedded database used by MONyog. It came out as expected.

Also the graphics 'looks and feel' and the documentation is now vastly improved.
See screenshots: http://www.webyog.com/en/screenshots_monyog.php

Additionally we will start releasing 64 bit binaries for Linux from this week.
Downloads: http://www.webyog.com/en/downloads.php



For the near future we will now focus on identifying 'problematic queries' (in addition to what the current 'processlist' feature already does). We will add:

* Server log analysis. With the combined MySQL access and Shell access that is possible from MONyog we will be able to handle logs stored as files or as database tables (as of MySQL 5.1+).

* Additionally we will add an option to record a 'pseudo server log' (internal code name for this is 'query sniffer') for the MySQL servers that MONyog connects to. This is useful if log analysis is only temporarily required and/or if logging on the server side is not desired for some reason.

Code for those two last features is now almost completed.


* Also basic LAMP monitoring (basic Apache and PHP metrics) will be added soon.



Which of the above featues will be included in the final 2.0 release and what will come shortly after in other 2.x releases (like 2.1 and 2.5) is not important in my opinion. Matter matters - numbers don't! Basically this is mostly a task of managing the workflow in our organisation and respond to important deadlines with stable releases. But it will all be here before end of this spring.



Detailed engine-specific counters (most important still of course InnoDB counters) has not 'gone away' (only the server does sometimes!) from our plans, but priorities were changed a little due to user requests. We had overwhelming responses from users after the 1.5 release. SSH-tunneling and LAMP monitoring were 'promoted' due to those requests. MONyog development always was and will continue to be very attentive to user requests.

Examples:

1) This is not a bug. The behaviour is documented at .... . REALLY!! So it is a documented bug then!
2) This is not a bug. This behaviour is by design. WOW!! So it is a design bug then!


Just food for thought! More?