https://bugs.freedesktop.org/show_bug.cgi?id=77048
--- Comment #6 from Mark Rotteveel <[email protected]> --- Unfortunately, my predecessor did not explicitly document the problems with OpenOffice (and probably LibreOffice) which lead to the introduction of the separate protocol. Looking at the OpenOffice specific protocol in Jaybird, the issues were: 1. DatabaseMetaData.getSchemas() expects at least one schema to be reported (Firebird doesn't have schemas, so reports none) 2. Various metadata is queried with a specific schema instead of null or "" 3. Expectation that resultset remains open after commit 4. When rights are assigned through a role (either a connection specific role, or the PUBLIC role), tables are read-only as the GRANTEE column is expected to have the same value as the current user (http://tracker.firebirdsql.org/browse/JDBC-226, http://tracker.firebirdsql.org/browse/JDBC-252) With Jaybird 2.2.4 in LibreOffice 4.2.2.1 I tried to reproduce these issues: Ad 1. No longer occurs Ad 2. No longer occurs (and a later change in Jaybird ignored schema in metadata queries) Ad 3. Either this no longer occurs or I can't find the specific conditions to trigger it (I will dig deeper); another possibility is that this was actually caused by a bug in Jaybird: http://tracker.firebirdsql.org/browse/JDBC-304 and/or http://tracker.firebirdsql.org/browse/JDBC-305 seem likely candidates Ad 4. This problem still exists, but can be worked around by disabling the privilege check in the advanced options (which might have some negative user experience effects like error messages when the update is not allowed) or using the jdbc:firebirdsql:oo: protocol. For most metadata methods JDBC implies (a variant of) the INFORMATION_SCHEMA or DEFINITION_SCHEMA defined in the SQL standard. Looking at the SQL:2011 Schemata book (section 5.62 TABLE_PRIVILEGES view and 6.52 TABLE_PRIVILEGES base table) the default implementation in Jaybird uses the right values for the GRANTEE column (namely the username for user-assigned rights and the rolename for role assigned rights), but Jaybird reports all privileges of all users and roles (as in the 6.52 table definition) instead of only those available to the current user under his currently enabled roles (as in the 5.62 view definition). The wording in the JDBC API documentation doesn't make clear what is actually expected. Either LibreOffice would need to also check the privileges for GRANTEE values PUBLIC and the current role but there is no standard mechanism in JDBC to query what the current role is, and/or Jaybird should only report the privileges of the current user (both user- and role-assigned); but then LibreOffice would have to assume that all reported privileges are for the current user which isn't true for existing Jaybird versions and might not hold with other JDBC driver implementations either. So to summarize: the issues that lead to the introduction to the separate protocol either no longer exist (1+2, at least not in LibreOffice), are not (yet) reproducible or might have been a bug in Jaybird itself (3), or are simply a problem that given the definition in JDBC are not really solvable. I have updated the crass wording in the jaybirdwiki that the expectations by LibreOffice do not comply with the JDBC specification to "the interpretation of the JDBC standard by Jaybird differs from the interpretation by OpenOffice / LibreOffice" and as far as I can tell that is only really relevant for item 4. I will take a closer look at issue 3 to see if I can still reproduce that, but at this point I'd say that there is nothing that needs to be fixed in LibreOffice. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
