This is also reproducible in LO 3.3.4 on Mac OSX

Tested also with my own build from master :
Version 3.7.0.0.alpha0+ (Build ID: 042686d)

Same problem.


Alex

Reproducible also on Windows XP with LO 3.3.4

Alex

Changed platform to all after testing on Windows.

Alex

Just for comparative purposes, if I use the JDBC connector, then the Relations dialog gets called, displayed, and is usable.


Alex

More experimentation.

I finally discovered that the Relationship menu entry will actually show up, but it took 16 minutes or so to get there on my MacbookPro with OSX Lion (10.7.4). In the meantime LO appears to remain frozen and Apple's system indicates that the app is not responding.

One possible reason for this is that LO fetches all of the relations for all of the databases hosted by the server !!

The irony of the situation is that for the particular database I wanted to call up the relationship dialog on, there are no previously existing relationships, so a user is lead to believe that the application has just died.

I remember seeing an option to filter out the unwanted databases somewhere, I will try that and see if it makes a difference. 



Alex

Changing subject headline to better reflect the problem.

The corresponding wait using a JDBC connector is less than 30 seconds.

Setting the database filter speeds things up to about the same performance as the JDBC connector _without_ filtering, so a workaround, but performance-wise still not good, this is after all a C++ connector which is supposed to be integrated into the LO environment and not have the performance hit of Java UNO / JNI calls.


Lowering priority and importance.


Alex

PS : All tests carried out with Oracle Mysql Connector extension, since my current same build as master compiled connector causes LO to crash while attempting to pass the ID/pwd parameters to the db server.


Alex

(In reply to comment #7)
> Changing subject headline to better reflect the problem.
> 
> The corresponding wait using a JDBC connector is less than 30 seconds.


That should read, less than **3** seconds.

Alex

Just to sum up :

MySQL Oracle Native Connector extension : 

- unfiltered database list = 16 min to display Relationships dialog
- filtered database list = approx 30 seconds to display Relationaships dialog




MySQL JDBC Connector 5.1.18 :

there is no need to filter the database list, it is apparently prefiltered by the driver = less than 3 seconds to display Relationships dialog


Tested on LO Master, Version 3.7.0.0.alpha0+ (Build ID: 8c05d8b)


Alex

Adding self to CC if not already on

Still present in 

Version: 5.0.3.2
Build ID: e5f16313668ac592c1bfb310f4390624e3dbfb75
Locale : fr-FR (fr.UTF-8)

OSX 10.11.2

Testing of this is blocked by bug 107579

Setting Assignee back to default. Please assign it back to yourself if you're
still working on this issue

Bug still present in 

LO5412 OSX 10.12.6

On pc Debian x86-64 with master sources updated 2 days ago, I could open the relationship part but I noticed this on console:
warn:legacy.osl:3698:3698:connectivity/source/commontools/dbmetadata.cxx:332: DBG_UNHANDLED_EXCEPTION in bool dbtools::DatabaseMetaData::supportsRelations() const
    type: com.sun.star.sdbc.SQLException
    message: supportsIntegrityEnhancementFacility: feature not implemented.
    context: N12connectivity6mysqlc17ODatabaseMetaDataE

Here is the path:
1) bool DatabaseMetaData::supportsRelations() const
https://opengrok.libreoffice.org/xref/core/connectivity/source/commontools/dbmetadata.cxx#322

2) sal_Bool SAL_CALL ODatabaseMetaData::supportsIntegrityEnhancementFacility()
https://opengrok.libreoffice.org/xref/core/mysqlc/source/mysqlc_databasemetadata.cxx#395

3) mysql-connector-cpp/driver/mysql_metadata.cpp
bool
MySQL_ConnectionMetaData::supportsIntegrityEnhancementFacility()
{
        CPP_ENTER("MySQL_ConnectionMetaData::supportsIntegrityEnhancementFacility");
        throw sql::MethodNotImplementedException("MySQL_ConnectionMetaData::supportsIntegrityEnhancementFacility");
        return false; // This will shut up compilers
}

I don't know if mariadb c connector implements this or not but it seems that we'll be stuck at least until we upgrade mysql c++ connector or patch it locally.

Lionel: I tried to search a newer mysql c++ connector on Oracle website (+ a free account), I found 1.1.9 but https://dev.mysql.com/downloads/connector/cpp/ provides a tar with only include files.

(In reply to Julien Nabet from comment #19)

> Lionel: I tried to search a newer mysql c++ connector on Oracle website (+ a
> free account),

On the downloads, there is a small "no thanks, just let me download" below the big "login" and "sign up" boxes.

> I found 1.1.9 but
> https://dev.mysql.com/downloads/connector/cpp/ provides a tar with only
> include files.

Choose "Source Code" as Operating System instead of "Linux".

(In reply to Lionel Elie Mamane from comment #20)
> ...
> On the downloads, there is a small "no thanks, just let me download" below
> the big "login" and "sign up" boxes.
I got an Oracle account but you're right!

> ...
> Choose "Source Code" as Operating System instead of "Linux".
Indeed, I had missed it.

I downloaded 1.1.9 version but I still see:
bool
MySQL_ConnectionMetaData::supportsIntegrityEnhancementFacility()
{
	CPP_ENTER("MySQL_ConnectionMetaData::supportsIntegrityEnhancementFacility");
	throw sql::MethodNotImplementedException("MySQL_ConnectionMetaData::supportsIntegrityEnhancementFacility");
	return false; // This will shut up compilers
}

I took a look to mysql-connector-c++-8.0.5-dmr-src but seems quite different. Moreover, I haven't seen "supportsIntegrityEnhancementFacility" keyword.

The strange this is on pc Debian x86-64 with master sources updated today, with odb linked to a Mysql db, I could entered Relationship screen and create relationships.
The only thing is LO remembers the last added relation because when  
I saved, reopened the file, only the last added relation was there.
If I add the first one again, save and reopen, both appear.
Now if remove both relations (and keep the tables on the screen), save and reopen, both relations don't appear.

Running in a lldb session, I have to interrupt the hung thread, and then running a backtrace, I see this :

* frame #0: 0x00007fff5d147082 libsystem_kernel.dylib`__recvfrom + 10
    frame #1: 0x0000000183ac3a5c libmysqlcppconn.dylib`vio_read(vio=0x000000017fab1980, buf=")", size=4) at violite.c:247
    frame #2: 0x0000000183ac4cbf libmysqlcppconn.dylib`my_real_read(net=0x000000010b3da600, complen=0x00007ffeefbfe110) at net.c:577
    frame #3: 0x0000000183ac4b99 libmysqlcppconn.dylib`my_net_read(net=0x000000010b3da600) at net.c:719
    frame #4: 0x0000000183ac94a1 libmysqlcppconn.dylib`net_safe_read(mysql=0x000000010b3da600) at libmariadb.c:369
    frame #5: 0x0000000183acd51b libmysqlcppconn.dylib`mthd_my_read_query_result(mysql=0x000000010b3da600) at libmariadb.c:2274
    frame #6: 0x0000000183ad8e81 libmysqlcppconn.dylib`mysql_stmt_execute(stmt=0x0000000186e7b9b0) at my_stmt.c:1490
    frame #7: 0x0000000183aa97e3 libmysqlcppconn.dylib`sql::mysql::MySQL_Prepared_Statement::do_query(this=0x0000000186d40ac0) at mysql_prepared_statement.cpp:427
    frame #8: 0x0000000183aa9ca5 libmysqlcppconn.dylib`sql::mysql::MySQL_Prepared_Statement::executeQuery(this=0x0000000186d40ac0) at mysql_prepared_statement.cpp:495
    frame #9: 0x0000000183a9d543 libmysqlcppconn.dylib`sql::mysql::MySQL_ConnectionMetaData::getImportedKeys(this=0x000000010ab8f6f0, catalog=<unavailable>, schema=0x00007ffeefbfe628, table=0x00007ffeefbfe568) at mysql_metadata.cpp:2713
    frame #10: 0x00000001839a6c25 mysqlc.uno.dylib`connectivity::mysqlc::ODatabaseMetaData::getImportedKeys(this=0x00000001804b7d28, catalog=<unavailable>, schema=0x00007ffeefbfe700, table=0x00007ffeefbfe6f8) at mysqlc_databasemetadata.cxx:1251
    frame #11: 0x00000001839a71f2 mysqlc.uno.dylib`non-virtual thunk to connectivity::mysqlc::ODatabaseMetaData::getImportedKeys(this=<unavailable>, catalog=<unavailable>, schema=<unavailable>, table=<unavailable>) at mysqlc_databasemetadata.cxx:0
    frame #12: 0x00000001889de8a6 libdbulo.dylib`(anonymous namespace)::RelationLoader::run(this=0x00000001804d13d0) at RelationController.cxx:334
    frame #13: 0x00000001889ddaa4 libdbulo.dylib`dbaui::ORelationController::loadData(this=0x0000000180483820) at RelationController.cxx:521
    frame #14: 0x00000001889dd521 libdbulo.dylib`dbaui::ORelationController::impl_initialize(this=0x0000000180483820) at RelationController.cxx:230


Not quite sure why ConnectionMetaData::getImportedKeys can't pick up the catalog (unavailable) 

or

 maybe the hang is due to network lookup failing to return a statement result set (frames 1 to 5) ?

On resumption after breaking out, the Relations for the entire database schemas are displayed. This would seem to suggest that there is mutex waiting to be released or acquired or a mutex race condition somewhere between retrieving the relationship data and handing off to the drawing of the window and painting of the data.

Enclosing a backtrace that perhaps someone else can better understand than I can.

Created attachment 137642 [details]
Lldb session full bt

Bug still present in 

Version: 6.3.0.0.alpha0+
Build ID: 284dd58e326e61a5d84bde367e1e4873dd738c76
CPU threads: 4; OS: Mac OS X 10.14.1; UI render: default; VCL: osx; 
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2018-11-22_23:09:13
Locale: fr-FR (fr_FR.UTF-8); UI-Language: en-US
Calc: threaded

Still reproducible on macOS 11 BigSur with Mac silicon chip M1.

Version: 7.0.3.1
Build ID: d7547858d014d4cf69878db179d326fc3483e082
CPU threads: 8; OS: Mac OS X 10.16; UI render: default; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR
Calc: threaded

I gave a new try with LO Debian package 7.3.0.2 and with master sources updated today + gen rendering in both cases, no pb to open relationship dialog, add 2 tables and link them.
Now it's just for the record since it was on Linux not in Mac or Windows as reported.

Problem seems to be solved for me at least with:

Version: 7.2.5.2 / LibreOffice Community
Build ID: 499f9727c189e6ef3471021d6132d4c694f357e5
CPU threads: 8; OS: Mac OS X 12.1; UI render: default; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR
Calc: threaded