Hi Guido, See my comments below.

Hi,

I'm having some problems switching one of our Java/Glassfish-based web applications over from MySQL to to MariaDB.

Since the MariaDB project advertises the software as a fully compatible

drop-

in replacement for MySQL, the first thing I did was simply stop the MySQL server, uninstall it, and then install and start MariaDB (5.5.28a, from

Gentoo

portage). We have got several C/C++ based application that access our MySQL databases. Those took a recompile, but afterwards continued to work as if nothing had happened.

Ideally, you do not have to recompile client-side. Client applications should continue working without recompilation. If this was not possible, could you please file a bug (details on bug system below)

I didn't have as much luck with our glassfish-based web frontend though.

The

first problem was that the existing MySQL connector is apparently unable

to

connect to MariaDB, so I deleted the existing JDBC Connection Pools and replaced them with new ones using the MariaDB Java Client instead. This worked on the surface, however now I'm getting a lot of exceptions whenever I'm accessing parts of the application that make use of BINARY type columns. According to the developer (of the web application on question), this is because either MariaDB itself or the connector are returning binary

columns

as type string, causing the persistance layer to attempt to convert them to a string object. Since the binary columns in question contain various unprintable characters, including zero-bytes, this fails.

Can someone please help me with these problems?

3 things:

- First , you should be able continue to work with ConnectorJ and if that did not happen , there is a server bug we would like to hear about. The claim of drop-in means you can exchange the server, and you do not have to do anything else. If that does not work, there is a bug that we would like to hear about. We use JIRA as our bug system and normally, bugs are filed here https://mariadb.atlassian.net . Please include as much information as you can about as bug as possible.

- Second. MariaDB JDBC Java Client. Would it be possible to get your developer to create a small yet self-contained test case for the bug he described , like the one below (I tried to follow the description in your mail, but failed to reproduce, the test for write some binary => read some binary back succeeds, for me)

@Test public void testBinary() throws Exception { Statement st = connection.createStatement(); st.execute("drop table if exists bintest"); st.execute("create table bintest (b varbinary(100))"); st.execute("insert into bintest values(0x0102)"); ResultSet rs = st.executeQuery("select * from bintest"); rs.next();

byte[] buf = (byte[])rs.getObject(1); assertEquals(2,buf.length); assertEquals(0x1,buf[0]); assertEquals(0x2,buf[1]); }

Please file it in jira https://mariadb.atlassian.net ("Create Issue" , set project to "MariaDB client library for Java app...")

- Third. If there is lack of clarity about it - MariaDB JDBC does not have the ConnectorJ heritage and does not claim to be drop-in replacement in all cases. It is another JDBC driver, and as much as standard is concerned, we strive for standard compatibility. We aim for good standard coverage, and we do also for compatibility with ConnectorJ in the cases where it is reasonable, however we can't support all hundreds of JDBC URL parameters with exactly the same semantics. Perhaps we can support dozen or so important parameters, but that will be it. If you lack a feature or two, please let us know (again, via Jira it will work best)

Cheers, Wlad