Bug 128950 - With LO Base 6.2, it is no longer possible to change the Database connection type in "MySQL (Native)"
Summary: With LO Base 6.2, it is no longer possible to change the Database connection ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
6.2.0.1 rc
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2019-11-22 10:00 UTC by Jean-Paul
Modified: 2022-04-13 09:47 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
dropdown options in LO 6163 vs 6201 (154.86 KB, image/jpeg)
2019-11-22 10:07 UTC, Jean-Paul
Details
on Ubuntu 18.04 with LO 6.3.3.2 (45.94 KB, image/png)
2019-11-22 21:56 UTC, Stang
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jean-Paul 2019-11-22 10:00:26 UTC
In LibreOffice Base, starting with 6.2.0.1, it is no longer possible to change the Database connection type in "MySQL (Native)".
I used to work with the MySQL jdbc driver, and want to change to the new MySQL Native driver. That option is no longer available in an existing Base file with Edit / Database> / Connection Type...
I can create new Base files with the Databse connection type "MySQL (Native)", but I can not change existing Base files.
Comment 1 Jean-Paul 2019-11-22 10:07:15 UTC
Created attachment 156034 [details]
dropdown options in LO 6163 vs 6201
Comment 2 Julien Nabet 2019-11-22 10:32:42 UTC
Could you give a try to last LO version 6.3.3?
Indeed, I can see Mysql direct (= native) on Win10 with LO 6.3.3
Comment 3 Alex Thurgood 2019-11-22 11:18:10 UTC
No repro with

Version: 6.3.3.2
Build ID: a64200df03143b798afd1ec74a12ab50359878ed
Threads CPU : 8; OS : Mac OS X 10.14.6; UI Render : par défaut; VCL: osx; 
Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR
Calc: threaded

I see a general entry called MySQL, choosing this and then clicking Next takes you to the choice of connections (ODBC, JDBC, native).
Comment 4 Alex Thurgood 2019-11-22 11:20:00 UTC
Also tested with

Version: 6.2.8.2
Build ID: f82ddfca21ebc1e222a662a32b25c0c9d20169ee
Threads CPU : 8; OS : Mac OS X 10.14.6; UI Render : par défaut; VCL: osx; 
Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR
Calc: threaded

No repro, WFM.
Comment 5 Stang 2019-11-22 21:55:02 UTC
Have seen the same with recent versions and currently on Ubuntu 18.04 with:

Version: 6.3.3.2
Build ID: a64200df03143b798afd1ec74a12ab50359878ed
CPU threads: 8; OS: Linux 5.0; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded

There is no other selection from Edit / Database> / Connection Type...

Will attach screenshot.
Comment 6 Stang 2019-11-22 21:56:38 UTC
Created attachment 156051 [details]
on Ubuntu 18.04 with LO 6.3.3.2
Comment 7 Julien Nabet 2019-11-22 22:09:02 UTC
On pc Debian x86-64 with master sources updated today, I could reproduce this.

If I create MYSQL/JDBC file then try to change it to Mysql Native, it doesn't appear.
Sorry I had misread the initial comment.
Comment 8 Julien Nabet 2019-11-22 22:22:35 UTC
Pb is due to this part
118 // skip mysql connection variations. It is handled in another window.
119 if(sURLPrefix.startsWith("sdbc:mysql:") && !sURLPrefix.startsWith("sdbc:mysql:jdbc:"))
120   continue;

Commenting this block makes Mysql Native Mysql ODBC appear

(see https://cgit.freedesktop.org/libreoffice/core/commit/?id=b2cefc2e36925b4384eb0aea54aa2c6bcfb018a8)

Tamás: any thoughts here?
Comment 9 Julien Nabet 2019-11-23 09:28:34 UTC
I submitted a patch on gerrit to facilitate discussion:
https://gerrit.libreoffice.org/#/c/83547/
Comment 10 Alex Thurgood 2019-11-25 07:38:17 UTC
There is also a similar bug report pending for the display choice of available MySQL database connections in the mailmerge module. Ideally, everything should be consistent. Currently, we have 3 different displays depending on how the user accesses the list choice of db connections.
Comment 11 Alex Thurgood 2019-12-02 12:53:37 UTC
For the bug requiring consistency in the listing of available DB connections, see also bug 127665
Comment 12 QA Administrators 2021-12-02 04:43:49 UTC Comment hidden (obsolete)
Comment 13 Jean-Paul 2021-12-04 17:08:14 UTC
Hello,

I tested the bug today, and I can confirm it is still present.

Below is the information from the Help - About LibreOffice :

Version: 7.2.2.2 (x64) / LibreOffice Community
Build ID: 02b2acce88a210515b4a5bb2e46cbfb63fe97d56
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: nl-BE (en_BE); UI: en-US
Calc: threaded

The bug was present since LO Base 6.2, when the Native MySQL connector became integrated in Base.
Comment 14 Julien Nabet 2021-12-05 21:02:01 UTC
Lionel/Alex/Robert: just wondering, what's the purpose to have only 1 Mysql entry,  just to limit the number of entries? I mean we could list all the Mysql (and removing the replacing process in the display name, see https://opengrok.libreoffice.org/xref/core/dbaccess/source/ui/dlg/generalpage.cxx?r=14cfff50#560) to have:
MySQL (JDBC)
MySQL (ODBC)
MySQL Connector (or rather "MySQL (Native)" if changing connectivity/registry/mysqlc/org/openoffice/Office/DataAccess/Drivers.xcu ?)
and remove the specific Mysql dialog.

Alex: what was the pb with mailmerge? (I gave a try but didn't see anything related to MySQL dialog even after having declared a MySQL DB in tools/options, I must have missed it I suppose)

(another thing too, should we replace "MySQL" by "MariaDB" for these? I mean for native part at least, it's MariaDB and with the time there will be noticeable differences between MySQL and MariaDB I suppose).
Comment 15 Robert Großkopf 2021-12-06 15:44:27 UTC
The difference between the listbox while creating a database → connecting to an existing database
and changing the connection of an existing database is irritating.

I would prefer to get the same listbox while trying to change the connection as it is offered while creating a new database.

I would call all the connections as "MariaDB(MySQL)".

MariaDB(MySQL) and PostgreSQL are the only databases, which are used with the internal native driver and through JDBC and ODBC. So it is a good idea to limit the entries by setting a subfolder for these three entries for every database.
Comment 16 Julien Nabet 2021-12-06 21:46:28 UTC
(In reply to Robert Großkopf from comment #15)
> ..
> MariaDB(MySQL) and PostgreSQL are the only databases, which are used with
> the internal native driver and through JDBC and ODBC. So it is a good idea
> to limit the entries by setting a subfolder for these three entries for
> every database.

Thank you for your feedback Robert.
With this patch, LO displays one generic "MYSQL" entry in both cases.
diff --git a/dbaccess/source/ui/dlg/generalpage.cxx b/dbaccess/source/ui/dlg/generalpage.cxx
index e3bacdefbc73..6d4f99e07436 100644
--- a/dbaccess/source/ui/dlg/generalpage.cxx
+++ b/dbaccess/source/ui/dlg/generalpage.cxx
@@ -304,6 +304,18 @@ namespace dbaui
 
     bool OGeneralPage::approveDatasourceType( ::dbaccess::DATASOURCE_TYPE eType, OUString& _inout_rDisplayName )
     {
+
+        switch ( eType )
+        {
+        case ::dbaccess::DST_MYSQL_JDBC:
+        case ::dbaccess::DST_MYSQL_ODBC:
+        case ::dbaccess::DST_MYSQL_NATIVE:
+            _inout_rDisplayName = "MySQL";
+            break;
+        default:
+            break;
+        }
+
         if ( eType == ::dbaccess::DST_MYSQL_NATIVE_DIRECT )
         {
             // do not display the Connector/OOo driver itself, it is always wrapped via the MySQL-Driver, if
@@ -559,17 +571,6 @@ namespace dbaui
 
     bool OGeneralPageWizard::approveDatasourceType( ::dbaccess::DATASOURCE_TYPE eType, OUString& _inout_rDisplayName )
     {
-        switch ( eType )
-        {
-        case ::dbaccess::DST_MYSQL_JDBC:
-        case ::dbaccess::DST_MYSQL_ODBC:
-        case ::dbaccess::DST_MYSQL_NATIVE:
-            _inout_rDisplayName = "MySQL";
-            break;
-        default:
-            break;
-        }
-
         return OGeneralPage::approveDatasourceType( eType, _inout_rDisplayName );
     }

The pb is how to call OMySQLIntroPageSetup for the changing connection case and I must recognize I don't understand the mechanism of RoadmapWizardMachine/wizardmachine/dbwiz/dbwizsetup

Lionel: if you got some idea, don't hesitate. As for me, I'm stuck.
Comment 17 Alex Thurgood 2021-12-06 22:21:26 UTC
(In reply to Julien Nabet from comment #14)
> 
> Alex: what was the pb with mailmerge? (I gave a try but didn't see anything
> related to MySQL dialog even after having declared a MySQL DB in
> tools/options, I must have missed it I suppose)
> 

From memory, the list choices weren't the same. 
I would need to check again to see if it has gone away.
Comment 18 Alex Thurgood 2021-12-06 22:38:16 UTC
(In reply to Julien Nabet from comment #14)
> Lionel/Alex/Robert: just wondering, what's the purpose to have only 1 Mysql
> entry,  just to limit the number of entries?

I seem to recall that we did this originally, ie. a single long list of connection possibilities. 

I don't remember now why the the drill down second step dialog was introduced, probably to make the choice selection more focussed and to differentiate it from general JDBC connections, as it might have been felt that there were too many choices in the initial dialog. 

If we were to continue down that route, we should consider doing the same for Postgresql and other dB backends such as Sqlite or similar which have multiple connector possibilities.

I fear however, that that would only complexify the UI code further. I have no strong opinion either way.
Comment 19 Alex Thurgood 2021-12-07 11:24:44 UTC
(In reply to Julien Nabet from comment #14)


> 
> Alex: what was the pb with mailmerge? (I gave a try but didn't see anything
> related to MySQL dialog even after having declared a MySQL DB in
> tools/options, I must have missed it I suppose)

Julien, the problem with the available mailmerge datasource list menu is described in bug 127665, and is still there.
Comment 20 Alex Thurgood 2021-12-07 11:30:49 UTC
(In reply to Alex Thurgood from comment #18)
> (In reply to Julien Nabet from comment #14)
> > Lionel/Alex/Robert: just wondering, what's the purpose to have only 1 Mysql
> > entry,  just to limit the number of entries?
> 
> I seem to recall that we did this originally, ie. a single long list of
> connection possibilities. 
> 

Indeed, the complete list of possibilities was present in LO4162 in the datasource dropdown menu (except for the various postgresql possibilities, as only one was given for that db, i.e. the native connector.)

Seems that this whole thing is a bit of a UI mess that was never unified in any meaningful way.
Comment 21 Julien Nabet 2021-12-07 18:15:48 UTC
(In reply to Alex Thurgood from comment #19)
> ...
> Julien, the problem with the available mailmerge datasource list menu is
> described in bug 127665, and is still there.

Thank you for the pointer!
Taking a look at https://bugs.documentfoundation.org/attachment.cgi?id=154552 for mailmerge, it corresponds to the simplest case since there's no entries grouping.
But since grouping is wanted, it requires to understand the complicated mechanism that I was talking about in my previous comment.
Comment 22 Julien Nabet 2021-12-08 21:52:47 UTC
(In reply to Alex Thurgood from comment #20)
> (In reply to Alex Thurgood from comment #18)
> > (In reply to Julien Nabet from comment #14)
> > > Lionel/Alex/Robert: just wondering, what's the purpose to have only 1 Mysql
> > > entry,  just to limit the number of entries?
> > 
> > I seem to recall that we did this originally, ie. a single long list of
> > connection possibilities. 
> > 
> 
> Indeed, the complete list of possibilities was present in LO4162 in the
> datasource dropdown menu (except for the various postgresql possibilities,
> as only one was given for that db, i.e. the native connector.)
> 
> Seems that this whole thing is a bit of a UI mess that was never unified in
> any meaningful way.

If we consider the 3 options of MySQL:
1) "MySQL ODBC": it goes to the same screen as choosing "ODBC" and there's no specific ODBC driver for MySQL in connectivity/source/drivers
so could be removed
2) "Connect Directly" the only one which should remain and be renamed with the name suggested by Robert, "MariaDB (MySQL)"
3) MySQL JDBC" which has indeed a specific driver in connectivity/source/drivers/mysql_jdbc
Reading https://en.wikipedia.org/wiki/Java_Database_Connectivity, there are 4 types of JDBC drivers:
"
Type 1 that calls native code of the locally available ODBC driver. (Note: In JDBC 4.2, JDBC-ODBC bridge has been removed[9])
Type 2 that calls database vendor native library on a client side. This code then talks to database over the network.
Type 3, the pure-java driver that talks with the server-side middleware that then talks to the database.
Type 4, the pure-java driver that uses database native protocol.
"
so I suppose MySQL JDBC corresponds to the second or the third driver.

Now, let's pause here.
Looking at git history of connectivity/source/drivers/mysql_jdbc/YUsers.cxx I saw this:
Revert removal of mysql jdbc connector
And also make some minor fixes so it cooperates with the new mysqlc
library.
...
-rw-r--r--	connectivity/registry/mysql_jdbc/org/openoffice/Office/DataAccess/Drivers.xcu	249	
-rw-r--r--	connectivity/source/drivers/mysql_jdbc/YCatalog.cxx	133	
-rw-r--r--	connectivity/source/drivers/mysql_jdbc/YColumns.cxx	74	
-rw-r--r--	connectivity/source/drivers/mysql_jdbc/YDriver.cxx	435	
-rw-r--r--	connectivity/source/drivers/mysql_jdbc/YTable.cxx	336	
-rw-r--r--	connectivity/source/drivers/mysql_jdbc/YTables.cxx	216	
-rw-r--r--	connectivity/source/drivers/mysql_jdbc/YUser.cxx	324	
-rw-r--r--	connectivity/source/drivers/mysql_jdbc/YUsers.cxx	101	
-rw-r--r--	connectivity/source/drivers/mysql_jdbc/YViews.cxx	146	
-rw-r--r--	connectivity/source/drivers/mysql_jdbc/Yservices.cxx	66	
-rw-r--r--	connectivity/source/drivers/mysql_jdbc/mysql_jdbc.component	26	
...

First I thought there were indeed mysql_jdbc and they have been removed by error but I noticed this:
https://cgit.freedesktop.org/libreoffice/core/commit/?id=26b40fcfc67480e75bd9959b0c5cb9db10fdf6a1
Moving mysqlc into connectivity as a library
Additionally I erased the remains of the old mysql C++ connector.

Also update the code where the clang plugins were unhappy after moving
the mysqlc module.

Remove mysql-cpp-connector external.
...
-rw-r--r--	connectivity/source/drivers/mysql/YCatalog.cxx	138	
-rw-r--r--	connectivity/source/drivers/mysql/YColumns.cxx	78	
-rw-r--r--	connectivity/source/drivers/mysql/YDriver.cxx	492	
-rw-r--r--	connectivity/source/drivers/mysql/YTable.cxx	356	
-rw-r--r--	connectivity/source/drivers/mysql/YTables.cxx	216	
-rw-r--r--	connectivity/source/drivers/mysql/YUser.cxx	320	
-rw-r--r--	connectivity/source/drivers/mysql/YUsers.cxx	105	
-rw-r--r--	connectivity/source/drivers/mysql/YViews.cxx	151	
-rw-r--r--	connectivity/source/drivers/mysql/Yservices.cxx	69	
-rw-r--r--	connectivity/source/drivers/mysql/mysql.component	26	
...
So the same files but instead of connectivity/source/drivers/mysql, there were then in connectivity/source/drivers/mysql_jdbc

I thought it was the remnant of an ancient MySQL native connector then I noticed
getJavaDriverClass in mysql_jdbc/YDriver.cxx

In brief, first I wanted to simplify all this by displaying the 3 MySQL entries but it seems better to have a list not too long, then I thought we could remove these 2 extra MySQL entries and JDBC one isn't possible. Is it really useful to have this last one, I suppose it provides a bit more of features than the pure JDBC driver. Also, I've just realized that removing this part would break all the existing odb files which use this driver.
So back to the mess with the intermediary MySQL page, roadmachine, etc. :-(
Comment 23 Alex Thurgood 2021-12-11 09:21:18 UTC
(In reply to Julien Nabet from comment #22)

> 
> In brief, first I wanted to simplify all this by displaying the 3 MySQL
> entries but it seems better to have a list not too long, then I thought we
> could remove these 2 extra MySQL entries and JDBC one isn't possible. Is it
> really useful to have this last one, I suppose it provides a bit more of
> features than the pure JDBC driver. Also, I've just realized that removing
> this part would break all the existing odb files which use this driver.
> So back to the mess with the intermediary MySQL page, roadmachine, etc. :-(

Ouch !

FWIW, the old MySQL-JDBC specific set up dialog used to fetch the driver name automatically - I'm guessing that this is where that reference in YDriver.cxx is supposed to be called, but I'm not sure that it still does this ? (need to check).

This is a bit of a pickle with no easy get out :-(