bug report: A simple select that works fine with the sqlite driver but fails with the mysql one.

[pdenapo]

(Dear Vadim )

This is a bug report. The drivers for sqlite and mariadb do not seem to behave consistently in my example program (indeed t the later, do not seem to work at all!)

https://github.com/pdenapo/example_programs_in_D/tree/master/test_ddbc_select

I have created a database with a single table and a single row. I do a simple select statement

SELECT * FROM test WHERE name = 'John';

I want to get only the first result. It seems that the right way of doing that is my method

get_data_with_next()

At least it works with fine the sqlite driver !

(rs.next() seems to be required here, the documentation is not clear enough in my opinion).

However, if I try to run the very same program with the mysql driver (using MariaDb under Debian 10) it fails with an exception.

You can find the output from both cases (and the mariaDB shell in my respository.

[SingingBush]

First is that ddbc will not do anything to make SQL that you write change depending on the db type so it's worth checking that your CREATE and INSERT statements are working prior to the SELECT.

If you want to write D code that will work on a variety of databases without too many changes then it's worth looking at Hibernated.

I suggest looking at example/source/testddbc.d for some clues on using ddbc.

For one of the database type (can't remember but may have been MySQL) I had to create a new statement conn.createStatement() for subsequent SQL queries. That was for the pods support though.

[pdenapo]

Many thanks for your comments, Samael.

Yes, I had indeed verified that my CREATE and INSERT statements worked as expected, before submitting this bug report. Indeed, at

https://github.com/pdenapo/example_programs_in_D/blob/master/test_ddbc_select/results_with_mariadb_shell.txt

you can see the output of the mariaDB shell proving that!

Unfortunately your suggestion of using a new statement conn.createStatement() for subsequent SQL queries does not seem to help. Here is a new version of my test program modified for doing that:

https://github.com/pdenapo/example_programs_in_D/tree/master/test_ddbc_select_2

The results are the same! The cause of trouble should be another one...

[SingingBush]

Have you tried an older version of ddbc such as 0.3.9 or 0.4.3? Also, what mariadb version are you using? We use mysql-native for the MySQL/Mariadb driver. It's probably worth writing a quick bit of test code to see if the problem running those SQL statements exists when running a small project using mysql-native directly. Then we'll know if the problem is in ddbc or mysql-native.

[pdenapo]

I`m afraid that it is a problem with odbc. I have tried using mysql-native directly and it did work as expected. Please see https://github.com/pdenapo/example_programs_in_D/tree/master/test_mysql_native for my test program and for its output https://github.com/pdenapo/example_programs_in_D/blob/master/test_mysql_native/test_output.txt

[SingingBush]

I've checked and this is the same with 0.3.9, 0.4.3, and 0.5.0

I also tried with and without vibe-d. The section of code that throws the exception was last changed in April last year: update mysql-native to 2.2.1. Which is rather concerning. That would mean it's been broken since 0.3.7

Just to make sure I ran your code with dmd 2.088.0 and ddbc 0.3.7 and can see in the log:

get_data_with_next method
result with next=Smith

It still falls over after that though:

ddbc.core.SQLException@../../../.dub/packages/ddbc-0.3.7/ddbc/source/ddbc/drivers/mysqlddbc.d(213): Assertion failure
----------------
../../../.dub/packages/ddbc-0.3.7/ddbc/source/ddbc/drivers/mysqlddbc.d:213 void ddbc.drivers.mysqlddbc.MySQLConnection.close() [0x60626c]
source/app.d:80 _Dmain [0x6011c4]
core.exception.AssertError@../../../.dub/packages/mysql-native-1.1.4/mysql-native/source/mysql/protocol/sockets.d(121): Assertion failure
----------------
??:? _d_assertp [0x70ff65]
../../../.dub/packages/mysql-native-1.1.4/mysql-native/source/mysql/protocol/sockets.d:121 const void mysql.protocol.sockets.MySQLSocketVibeD.__invariant5() [0x6699e5]
../../../.dub/packages/mysql-native-1.1.4/mysql-native/source/mysql/protocol/sockets.d:107 const void mysql.protocol.sockets.MySQLSocketVibeD.__invariant() [0x669b9c]
../../../.dub/packages/mysql-native-1.1.4/mysql-native/source/mysql/protocol/sockets.d:126 void mysql.protocol.sockets.MySQLSocketVibeD.close() [0x669a12]
../../../.dub/packages/mysql-native-1.1.4/mysql-native/source/mysql/connection.d:469 void mysql.connection.Connection.kill() [0x65e01d]
../../../.dub/packages/mysql-native-1.1.4/mysql-native/source/mysql/connection.d:773 void mysql.connection.Connection.close() [0x65eb08]
../../../.dub/packages/ddbc-0.3.7/ddbc/source/ddbc/drivers/mysqlddbc.d:210 void ddbc.drivers.mysqlddbc.MySQLConnection.close() [0x6061ff]
source/app.d:80 _Dmain [0x6011c4]
core.exception.InvalidMemoryOperationError@src/core/exception.d(647): Invalid memory operation
----------------
Program exited with code 1

So this is indeed a problem. It's weird that it's not being detected in any tests.