Details
-
Task
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
None
-
None
Description
Problem :
We keep telling people that the client/server protocol that we use is the same as MySQL's.
We do not test it at all, the only testing that is regularly done for the server is implemented with C/C client that is also owned by us. C/C can have bugs, that can be compensated on the server site.
To fix this problem, we need to implement testing for protocol features. The probably single way to do that is to test server with more than just C/C. Perhaps, ideally we can run unit tests suites of the connectors that are not owned by us on buildbot.
There are several alternatives for choosing the connectors to test server against.
- libmysql by Oracle (or their Connector/C)
- C/J by Oracle
- C/NET by Oracle
- C/NET by comminuty https://github.com/mysql-net/MySqlConnector
- C/Python by Oracle (native python mode)
- perl DBI/DBD
- anything else ?
C/J by MariaDB is a viable alternative, not ideal (since it is aware of mariadb features), but still it does run against MySQL server by Oracle regularly, and is not as tied to the server as C/C
Now, to the test suites
- libmysql can be tested with mysql_client_test (part of the server).
- Our C/J can be unittested tested with maven
- https://github.com/mysql-net/MySqlConnector describes how to test with their connector
We can also do "program minimum" rather than run "program maximum" (full connector test suites), which is
connect/query with result set or update, same with prepared statement/disconnect.
Attachments
Issue Links
- relates to
-
-
- Open
-
-
MDEV-16347 Integer literal is typed as MYSQL_TYPE_LONG
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Open
-
-
-
- Closed
-
- links to
Activity
| Field | Original Value | New Value |
|---|---|---|
| Description |
Problem :
We keep telling people that the client/server protocol that we use is the same as MySQL's. We do not test it at all, the only testing that is regularly done for the server is implemented with C/C client that is also owned by us. C/C can have bugs, that can be compensated on the server site. To fix this problem, we need to implement testing for protocol features. The probably single way to do that is to test server with more than just C/C. Perhaps, ideally we can run ujnit tests suites of the connectors *that are not owned by us* on buildbot. There are several alternatives for choosing the connectors to test server against. - libmysql by Oracle (or their Connector/C) - C/J by Oracle - C/NET by Oracle - C/NET by comminuty https://github.com/mysql-net/MySqlConnector - C/Python by Oracle (native python mode) - perl DBI/DBD - anything else ? C/J by MariaDB is a viable alternative, not ideal (since it is aware of mariadb features), but still it does run against MySQL server by Oracle regularly, and is not as tied to the server as C/C Now, to the test suites - libmysql can be tested with mysql_client_test (part of the server). - Our C/J can be unittested tested with maven - https://github.com/mysql-net/MySqlConnector describes how to test with their connector We can also do "program minimum" rather than run "program maximum" (full connector test suites), which is connect/query with result set or update, same with prepared statement/disconnect. |
Problem :
We keep telling people that the client/server protocol that we use is the same as MySQL's. We do not test it at all, the only testing that is regularly done for the server is implemented with C/C client that is also owned by us. C/C can have bugs, that can be compensated on the server site. To fix this problem, we need to implement testing for protocol features. The probably single way to do that is to test server with more than just C/C. Perhaps, ideally we can run unit tests suites of the connectors *that are not owned by us* on buildbot. There are several alternatives for choosing the connectors to test server against. - libmysql by Oracle (or their Connector/C) - C/J by Oracle - C/NET by Oracle - C/NET by comminuty https://github.com/mysql-net/MySqlConnector - C/Python by Oracle (native python mode) - perl DBI/DBD - anything else ? C/J by MariaDB is a viable alternative, not ideal (since it is aware of mariadb features), but still it does run against MySQL server by Oracle regularly, and is not as tied to the server as C/C Now, to the test suites - libmysql can be tested with mysql_client_test (part of the server). - Our C/J can be unittested tested with maven - https://github.com/mysql-net/MySqlConnector describes how to test with their connector We can also do "program minimum" rather than run "program maximum" (full connector test suites), which is connect/query with result set or update, same with prepared statement/disconnect. |
| Link |
This issue causes |
| Link |
This issue relates to |
| Link |
This issue causes |
| Link |
This issue relates to |
| Link |
This issue relates to |
| Assignee | Elena Stepanova [ elenst ] | Daniel Black [ danblack ] |
| Link |
This issue relates to |
| Link | This issue relates to TODO-2639 [ TODO-2639 ] |
| Workflow | MariaDB v3 [ 85340 ] | MariaDB v4 [ 130778 ] |
| Link |
This issue relates to |
| Remote Link |
This issue links to "Connector/NET broken by |
| Rank | Ranked lower |
| Rank | Ranked higher |
| Labels | foundation |
| Component/s | External Projects [ 20221 ] | |
| Component/s | Tests [ 10800 ] | |
| Key | MDEV-15148 | MDBF-952 |
| Workflow | MariaDB v4 [ 130778 ] | MariaDB Foundation v1 [ 189438 ] |
| Project | MariaDB Server [ 10000 ] | MariaDB Foundation Development [ 11901 ] |
wlad great idea.
On other clients implementations with active communities:
Lots of these have travis tests already against mariadb to ensure their compatibility with released mariadb in the same way that this MDEV proposed to do the same in reverse.
Some communities above are missing tests against mariadb and and getting them to develop against released mariadb would help their mutual compatibility by release time too. Probably should notify these communities about MariaDB's protocol enhancements too.