Two problems I’m seeing in MySQL workbench in tumbleweed:
-
The “mysql” package in zypper is of course mariadb, and mariadb version is 10.0.
-
MySQL Workbench warns users that the version is incompatible. This is skippable, of course, if you continue, you can execute basic queries in the query window.
-
Not sure if it’s related, but I am unable to open any windows under the Server menu, most important to many users would be Users and Privileges, where you can create users and give them priveleges without knowing the mariadb/mysql syntax to do that task.
If this is a known/expected issue I suppose there’s no point logging this anywhere. Is there any other package that is an alternative to MySQL Workbench that will let me administer a mariadb 10.0 default instance on tumbleweed?
http://i.imgur.com/MrMSR7M.png
W
further details:
I open the app from the console and I can see this python traceback (call stack), which may explain why the admin menu fails to open silently… From my basic Python traceback reading skills it seems that the version parsing code is a bit stupid:
Traceback (most recent call last):
File “/usr/share/mysql-workbench/libraries/workbench/notifications.py”, line 34, in _the_observer
obs(name, sender, args)
File “/usr/lib64/mysql-workbench/modules/wb_admin_grt.py”, line 402, in attachToSQLEditor
context = AdministratorContext(sender)
File “/usr/lib64/mysql-workbench/modules/wb_admin_grt.py”, line 119, in init
self._check_instance_profile()
File “/usr/lib64/mysql-workbench/modules/wb_admin_grt.py”, line 156, in _check_instance_profile
if autoDetectLocalInstance(self.connection):
File “/usr/lib64/mysql-workbench/modules/wb_admin_grt.py”, line 487, in autoDetectLocalInstance
profiles = get_profiles_for(“Linux”, version)
File “/usr/lib64/mysql-workbench/modules/wb_admin_grt.py”, line 458, in get_profiles_for
profile_version = Version.fromstr(data.get(“serverVersion”))
File “/usr/share/mysql-workbench/libraries/workbench/utils.py”, line 161, in fromstr
match = re.match(r’^(\d+.\d+(.\d+)).$’, s.strip())
AttributeError: ‘NoneType’ object has no attribute ‘strip’
If I hack that place, there are other places in the python code that are broken, all because data.get(“serverVersion”) is failing.
I am going to download the latest python sources from github and see how fresh/stale this opensuse version is, and if this is an upstream source problem; incompatibility with mariadb 10.x version string syntax with what looks to me like some pretty ugly and weirdly factored version checking code in mysql workbench:
from wb_admin_grt.py:
for f in files:
data = grt.unserialize(os.path.join(path, f))
if data and data.has_key("sys.system") and data"sys.system"] == system:
profiles.append(data)
profile_version = Version.fromstr(data.get("serverVersion")) # data.get("servereVersion") FAILS!
W
It looks like this is expected, and that MySQL Workbench is basically useless and this is a known upstream issue. People don’t use MySQL Workbench with MariaDB 10.
W
Even building MySQL Workbench from sources, using latest github sources, is a HORRIBLE experience. After getting (I think) all dependencies installed, I find that the antlr parser and MySQL Workbench devs are at war, and I find a specific antlr jar that will process their antlr grammars, the results still don’t build, the resulting mysql-workbench/library/mysql.parser/MySQLSimpleParser.c is horribly broken (thousands of undefined symbols) of this sort;
/root/src/mysql-workbench/library/mysql.parser/MySQLSimpleParser.c:173855:44: error: ‘FOLLOW_set_in_option_type17253’ undeclared (first use in this function)
EXCEPTION->expectingSet = &FOLLOW_set_in_option_type17253;
Yuck. So heads up. If you want to use MySQL Workbench in Tumbleweed, don’t install Mariadb, and if you want to build your own MySQL Workbench from source, good luck with that. If anyone figures out how, please reply.
It seems to me that CMAKE’s version detection tools are braindead in that a single character 9.3.1 will be detected as “a version 5.x or higher” of MySQL, but that MariaDB fails to be recognized at all by CMAKE, because TWO characters (10.0.2) is one character two many for the major version, and so NO version is detected. If we modify CMakeLists.txt like this we can get past CMAKE brain-deadness:
find_package(MySQL 10.0.22 REQUIRED)
Everything is downhill from there. This is NOT a complaint about Tumbleweed, just a heads-up about an area of FOSS Ecosystem excessive composite design stupidity.
W
mysql is now controlled by Oracle what did you expect??
Here are some options
http://alternativeto.net/software/mysql-workbench/?platform=linux
The immediate fault is not with Oracle; mariadb have been saying for ages that they will not guarantee compatibility beyond 5.5. The number 10 was intended to drive this point home. Whether the longer term fault is Oracle’s or the founders’ for selling out to Sun is an interesting discussion point.