Hi Matthews and thanks to report this.

This is a strange error, because after reading code to identify the problem, the only way that can cause this issue, is that when preparing query, server send back that there is no parameter.

The thing is now to discover what kind of query can cause this. If you have any information about that, that would be great !
maybe it's related to MySQL (5.6.23) (we test against 5.6.28)

From what I can see, it looks like our application is failing when running through this schema creation.

It's possible this code (most of it from 2005) isn't ideal, but it has run fine with every MySQL JDBC driver (and older MariaDB JDBC). It's just nice to be able to package this driver with the software because the license is better and it works nice.

If it runs it on a regular statement/execute it looks to work fine, but not if it's a prepared statement. I'll attach a super simple test project that replicates this failure.

(Edited on 2016-02-24 to provide correct statement that was run)

CREATE TABLE CONTENT_COLLECTION
(
COLLECTION_ID VARCHAR (255) NOT NULL,
IN_COLLECTION VARCHAR (255),
XML LONGTEXT,
BINARY_ENTITY BLOB
);

CREATE UNIQUE INDEX CONTENT_COLLECTION_INDEX ON CONTENT_COLLECTION
(
COLLECTION_ID
);

CREATE INDEX CONTENT_IN_COLLECTION_INDEX ON CONTENT_COLLECTION
(
IN_COLLECTION
);

INSERT INTO CONTENT_COLLECTION VALUES ('/','',
'<?xml version="1.0" encoding="UTF-8"?>
<collection id="/">
<properties>
<property name="CHEF:creator" value="admin"/>
<property name="CHEF:is-collection" value="true"/>
<property name="DAV:displayname" value="root"/>
<property name="CHEF:modifiedby" value="admin"/>
<property name="DAV:getlastmodified" value="20020401000000000"/>
<property name="DAV:creationdate" value="20020401000000000"/>
</properties>
</collection>
', NULL)

Attached CONJ-244.zip

All this is is a modified ScriptRunner that uses prepared statements. All you should have to do is create an empty database, modify the connection into in MariaTest.java (or leave it localhost/mariatest/mariatest) and run this.

java -cp "mariadb-java-client-1.3.3.jar:." MariaTest

I possibly could change our application code from prepareStatement to createStatement and it works but it works with both with other JDBC drivers and doesn't seem like it should matter and that would be a huge change.

Thanks!

Have you had any chance to look at this. I've confirmed that it's not the MySQL version. I've tested it also with MariaDB with the same NPE in the driver. This is a problem with 1.3.3 and 1.3.4. The maria-db-client-1.2.3 works fine.

mysql Ver 15.1 Distrib 10.0.22-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2

Even running this query test (in the ZIP) against a MariaDB causes an NPE.

java.lang.RuntimeException: Error running script. Cause: java.lang.NullPointerException
at ScriptRunner.runScript(ScriptRunner.java:105)
at MariaTest.main(MariaTest.java:30)
Caused by: java.lang.NullPointerException
at org.mariadb.jdbc.internal.protocol.AbstractQueryProtocol.executePreparedQuery(AbstractQueryProtocol.java:567)
at org.mariadb.jdbc.MariaDbServerPreparedStatement.executeInternal(MariaDbServerPreparedStatement.java:281)
at org.mariadb.jdbc.MariaDbServerPreparedStatement.execute(MariaDbServerPreparedStatement.java:371)
at ScriptRunner.runScript(ScriptRunner.java:154)
at ScriptRunner.runScript(ScriptRunner.java:96)
... 1 more

Hi,

The version 1.3.6 has corrected this issue for https://mariadb.atlassian.net/browse/CONJ-257.
The only thing for example to work is change data type :

CREATE TABLE CONTENT_COLLECTION

(

COLLECTION_ID VARCHAR (255) NOT NULL,

IN_COLLECTION VARCHAR (255),

XML MEDIUMTEXT, #was LONGVARCHAR

BINARY_ENTITY VARBINARY(255), #was VARBINARY without size

CONSTRAINT CONTENT_COLLECTION_INDEX UNIQUE (COLLECTION_ID)

);

(LONGVARCHAR alias datatype doesn't exist in mariadb. see data types : https://mariadb.com/kb/en/mariadb/data-types/ you must use MEDIUMTEXT.)

It looks like my comment was incorrect, It's not actually LONGVARCHAR it's LONGTEXT (it is that LVC in the HSQLDB scripts which are deprecated).

It's correct in the sql in the zip file which I used for the test and I updated my comment. Not sure how that was incorrect I'll retest with 1.3.6 since it's super easy to verify one way or another. Thanks!

In either case, I just tested and 1.3.6 fixes this problem as well, you can mark this as resolved in 1.3.6. Thanks for the fix and update!

Ok, i close the issue so.