Devart is glad to release the new improved version of dbForge Studio for MySQL, v.6.1 Beta.

Devart is glad to release the new improved version of dbForge Studio for MySQL, v.6.1 Beta.

The MySQL Windows Experience Team is proud to announce the release of MySQL Notifier version 1.1.5, the  latest addition to the MySQL Installer for Windows.

MySQL Notifier 1.1.5 introduces the following features:

• The MySQL Utilities can now be opened from MySQL Notifier if installed separately from MySQL Workbench (it is no longer bundled with MySQL Workbench 6.x).
• Added Workbench connections edition capability right from the Monitor MySQL Server Instance window of the MySQL Notifier (accessed through Actions > Manage Monitored Items… > Add… > MySQL Instance). Any of the listed MySQL Workbench connections can be right-clicked and a new “Edit Connection” context menu is available for users to edit the Workbench connection properties.
• Changed the way the Workbench connections and servers files are monitored, now the Notifier detects automatically …

Percona is glad to announce the release of Percona Monitoring Plugins 1.1. The components are designed to integrate seamlessly with widely deployed solutions such as Nagios, Cacti and Zabbix, and are delivered in the form of templates, plugins, and scripts.

In this release we have added MySQL template for Zabbix 2.0.x adopted from the existing Cacti one.

Changelog:

* Added MySQL template for Zabbix 2.0.x (first release)
* Added FreeBSD support to Nagios plugins, partially rewritten pmp-check-unix-memory (bugs 1249575, 1244081)
* Added new options to ss_get_mysql_stats.php to better support pt-heartbeat (bugs 1253125, 1253130)
* ss_get_mysql_stats.php script was opening multiple connections to the server …

InnoDB Fulltext Search now supports plugin parser in MySQL 5.7.3 release. It is a compatible feature as for MyISAM Fulltext Search. So the syntax and usage remain to be largely the same.

A parser plugin can operate in either of two roles:

a) The plugin can replace the built-in parser. In this role, the plugin reads the input to be parsed, splits it up into words, and passes the words to the server (either for indexing or for word accumulation).

b) The plugin can act in conjunction with the built-in parser by serving as a front end for it. In this role, the plugin extracts text from the input and passes the text to the parser, which splits up the text into words using its normal parsing rules.

If you want to write your own full text plugin, please refer to http://dev.mysql.com/doc/refman/5.7/en/writing-full-text-plugins.html.

If you have a existing plugin parser for MyISAM, there would be some minor …

MariaDB 10, Galera and a case study on CCM Benchmark

read more

Percona is glad to announce the first RC release of Percona XtraDB Cluster 5.6 on December 18th, 2013. Binaries are available from downloads area or from our software repositories.

Based on Percona Server 5.6.15-63.0 including all the bug fixes in it, Galera Replicator 3.2 and on Codership wsrep API 5.6.15-25.2 is now the first …

Today, we congratulate the Fedora community on their newest release. We believe it is a great platform to run the real, official MySQL on, and today we are adding Fedora 20 support in our Yum repos. We have the latest MySQL Server 5.6, the latest 5.7 development release and Connector ODBC ready for you on […]

If you have been using certain DBMSs, or reading recent versions of the SQL standard, you are probably aware of the so-called “WITH clause” of SQL.
Some call it Subquery Factoring. Others call it Common Table Expression. A form of the WITH CLAUSE, “WITH RECURSIVE”, allows to design a recursive query: a query which repeats itself again and again, each time using the results of the previous iteration. This can be quite useful to produce reports based on hierarchical data. And thus is an alternative to Oracle’s CONNECT BY. MySQL does not natively support WITH RECURSIVE, but it is easy to emulate it with a generic, reusable stored procedure. Read the full article …

Currently, if you want to search a key using JSON UDFs you have to specify each its part as a separate argument to the function: JSON_CONTAINS_KEY(doc, 'root', 'child', 'child of child', 'child of child of child', etc.....). This way of working with parameters is easy for developer, less error-prone, but can be not very beautiful.

I was suggested by some of users to change it to '/parent/child/child-of-child/...' or to 'parent:child:child-of-child:...' There are, probably, can be other suggestions. What do you like the best? How do you feel about current style with separate argument for each key element? Should we change or extend this syntax?