fail to connect to local host

Hi @dass,

Some will say I'm partial to PostgreSQL. That's an understatement: I'm all in for PostgreSQL. And the reason is that MySQL changes too much. Version 8.0 has changed so many things on the metadata structure that certain software applications that work with that structure stopped working. This piece of code, for example:

09:55:35,715 ERROR [org.hibernate.tool.hbm2ddl.SchemaUpdate] (ServerService Thread Pool -- 52) HHH000388: Unsuccessful: create table ra_ent_dbconnectionentry (id integer not null auto_increment, databaseSchema varchar(255), host varchar(255), name varchar(255), passwd varchar(255), port varchar(255), system varchar(255), usrname varchar(255), propertiesMap_id integer, primary key (id))

It contains a field named system but now it is a reserved keyword, so MySQL cannot create a field with that name. (Try creating a field named CREATE and you will experience the same kind of rejection. Or probably not.). The other errors are derived from this and the fact that MySQL engineers decided not to allow secure connections on untrusted servers.

A piece of advice: use PostgreSQL if you can. If you can't, go with MariaDB. MySQL 8.0 is too flawed to be usable.

Sorry for the bad news, mate! Hope this helps.

All comments

Hi @dass,

The first section of your log reads this:

    java.runtime.name = Java(TM) SE Runtime Environment
   java.runtime.version = 11.0.1+13-LTS
   java.specification.name = Java Platform API Specification
   java.specification.vendor = Oracle Corporation
   java.specification.version = 11
   java.util.logging.manager = org.jboss.logmanager.LogManager
   java.vendor = Oracle Corporation
   java.vendor.url = http://java.oracle.com/
   java.vendor.url.bug = http://bugreport.java.com/bugreport/
   java.vendor.version = 18.9
   java.version = 11.0.1
   java.version.date = 2018-10-16

Please, if you can, uninstall Java 11 and install Java 8. Java 10+ is known to give problems, as not all the libraries used on RapidMiner Studio/Server have been updated to support this new scheme imposed by Oracle.

That's all.

All the best,

Thank you very much for the reply..i really appreciate it.. I have also tried the suggested method which is to uninstall the java 11 and install java 8.. but i am still facing the same current problem to connect to the local host. Below is the server log..

log2.txt

log2.txt

Hi @dass,

A piece of advice: use PostgreSQL if you can. If you can't, go with MariaDB. MySQL 8.0 is too flawed to be usable.

Sorry for the bad news, mate! Hope this helps.

thank you very much for the suggestion, it finally works...

Hello, @dass,

For further reference, and I apologize in advance for hijacking this thread to open a discussion on something else: did you use MariaDB or PostgreSQL?

If PostgreSQL, great! Welcome to the party. If MariaDB, great too! It means that MySQL users can switch to a database that is still compatible with RapidMiner (and other things) without having to learn how to use yet another piece of software.

As someone who has a lot of experience in managing databases (and please, count experience as my polite way of telling you how many times I screwed things up, as I'm not calling myself an expert), I will take the opportunity to explain why you shouldn't choose MySQL for your new systems and go with one the options I previously mentioned instead, so that you can make an educated choice. If I'm wrong, I'll blame the MySQL documentation, profusely apologise for not reading it all and still continue using PostgreSQL, but a few experiences from the past month are enough motivation for me to say this:

Keeping backwards compatibility is critical, and if someone breaks it, there should be something replacing the previous functionality. I haven't observed the effort to comply with this on MySQL development since Oracle began working on it. It puts a lot of stress on developers, and that's definitely not cool: until version 5.6 (or 5.7), I still could query the database metadata in a useful way to build interactive systems but that has changed.

How critical is backwards compatibility in a database, you wonder? The Linux operating system has just one rule: WE DO NOT BREAK USERSPACE! and there is a reason for that rule which also applies for databases. If we change the interface for userspace applications, the only way to make these applications run again is recompiling. If we change the interface used to communicate with the database, the only way to make these applications run again is rewriting queries and then rebuilding. It is paramount, and I can't stress that enough, it is paramount to avoid breaking backwards compatibility at will, especially if you do have a large user base (like MySQL has/had). If I do something and screw it up on the design of functionality A and then I regret it, I can build a fork and create a new functionality B that resembles the other, inform the users reading documentation on functionality A that it has been deprecated and that the new way to do things is functionality B and live with my mistake until I am pretty sure that a large base of users is aware about the solution, or build a trick that executes functionality B to satisfy the requirement of functionality A.

I repeat: if I am wrong, I will blame the documentation and apologise for not reading it from cover to cover and just investing three hours in performing Google searches for my problems instead, and continue using a database that hasn't given me this kind of problems at all over the past 20 years.

On the other hand, if you use Microsoft SQL Server and get offended by this thread, please don't be. Microsoft SQL Server is a great choice too, but I can't give an opinion on something I personally don't use. Apply the same rationale for Oracle.

All the best,

Rodrigo.