Database/Drivers/MySQL Native/Known Problems
This page lists the currently known problems with the MySQL Native Driver, aka MySQL Connector/OOo.
- 1 Empty schemata not shown
- 2 DECIMAL shown as TEXT
- 3 SMALLINT shown as REAL
- 4 OOo shows unrelated databases/schemata
- 5 No default schema on table creation
- 6 No way to set MySQL specific table attributes
- 7 Base does not recognize schema changes
- 8 table column comments not synced between MySQL and Base
- 9 Violation of FK constraint give two errors instead of one
- 10 Default values not properly processed
Empty schemata not shown
Create an empty schemata/database. Create a new Base database which connects to an empty MySQL database. The MySQL database is not shown.
Reason: OOo calls getTables() - no tables - schema not displayed. Setting might even be cached - verify that database becomes visible after creating table (from mysql prompt) in schema.
DECIMAL shown as TEXT
Base shows numerical DECIMAL columns as TEXT (in the table editor?).
I'm 95% sure C/C++ and C/OOo report a proper column type.
SMALLINT shown as REAL
When loading a table with a SMALLINT column it is shown as a FLOAT/REAL column in Base (in the table editor?)
Create a new Base database that connects to a MySQL schemata "test". Have "test" in the connection settings! OOo will ignore it and query MySQL for all tables in all schematas, and also display all those tables.
As a consequence the user will see all schemata he has access to not only the schemata/database "test" as requested in the connection settings
No default schema on table creation
Base does not preselect a default schema in the table editor dialog. Its does not even if you connect to a certain schema by specifying it in the connection settings.
No way to set MySQL specific table attributes
The Base table editor does not give access to table attributes. Not even basic ones such as the Engine (MyISAM: non-transactional, InnoDB: transactional).
Base does not recognize schema changes
After connecting to a database and opening a table once, Base will not recognize changes applied to the DB schema meanwhile when opening the table in the table editor again.
Is this really an issue? There's
View/Refresh Tables, if needed.
table column comments not synced between MySQL and Base
Base table column comments are not synchronized with the MySQL DB and its schema. Existing comments are not displayed in Base, and entering comments in the table editor is not propagated to MySQL.
That's a known issue with all database types. The column description as displayed in Base is purely client-side, and stored within the .odb file only. There's also an issue for this, but I'm too lazy too search for it right now ...
Violation of FK constraint give two errors instead of one
Create two tables. Have one table "derived" reference entries in the other table "source". Try to remove a referenced record from the table "source". MySQL will report an error stating that you are violating a FK constrain. When using the MySQL JDBC driver the Base shows one requester with stating something like "Error - (error message from MySQL)". When using the native driver you get an requester stating "error" and you can proceed to an error details dialog. In the details dialog you will find two errors. The first has no message, the second shows the error message provided by MySQL.
The empty error message is ugly, but not the only one within Base, so that's nothing which will block an 1.0 release ...
Default values not properly processed
The Base table editor neither properly sets default values nor does it re-engineer default values properly.
Again, this is a known issue. The default value displayed in the UI is a so-called "control default", which is applied to controls used to enter data into the given field. The DB-side default for a column is a different property, API-wise, and currently not evaluated at all. Probably not even properly fetched by most existing drivers.
Changing this is possible, but probably requires UI changes. First, we would need to define how the control default and the DB default should interact in the UI. A possible scenario would be to drop the UI support for the control default, and always use the DB default (even in controls), as long as the driver supports providing/accepting DB defaults.