For MySQL, we need to be able to force version 4.1. For PostgreSQL we need to able to force version 8.1.
We can use a property such as "force.database.product.version=4.1"
In ConnectionProperties.java Line 2515, instead of quering the DatabaseMetaData for the product version, we would use the property value.
We don't need a GUI for this, just need to the user to be able to edit the file and add the property.
Added handling of property force.database.product.version.
It will only accept a value formatted as x.y
Use Case :
MySQL 4.1 and below offers the "SHOW" commands to extract catalog data, while MySQL 5.0 and above offer the "information_schema" database for system catalog data. The problem some users are experiencing is a performance problem in the "information_schema" data of MySQL. We can't fix the MySQL problem as that would need to be fixed by Oracle. The only way around this, is if we allow users to make a connection to a MySQL 5.x server but telling Aqua Data Studio it is a MySQL 4.1 server. This will force Aqua Data Studio to use the SHOW commands instead of the "information_schema" database. This should work well. The only draw back is that the extra information provided in the "information_schema" system catalog tables will not be available to the user. For example, Table partitioning information will not be available.
Use Case :
MySQL 4.1 and below offers the "SHOW" commands to extract catalog data, while MySQL 5.0 and above offer the "information_schema" database for system catalog data. The problem some users are experiencing is a performance problem in the "information_schema" data of MySQL. We can't fix the MySQL problem as that would need to be fixed by Oracle. The only way around this, is if we allow users to make a connection to a MySQL 5.x server but telling Aqua Data Studio it is a MySQL 4.1 server. This will force Aqua Data Studio to use the SHOW commands instead of the "information_schema" database. This should work well. The only draw back is that the extra information provided in the "information_schema" system catalog tables will not be available to the user. For example, Table partitioning information will not be available.
I would rather see a special property which affects only the functionality under question, permitting fine grained control over the behavior of the program.
In this case, something like "mysql.use.show.command" which affects ONLY this functionality, while leaving other aspects of the app intact. There could be more cases like this which can not be addressed by a single property setting.
I would rather see a special property which affects only the functionality under question, permitting fine grained control over the behavior of the program.
In this case, something like "mysql.use.show.command" which affects ONLY this functionality, while leaving other aspects of the app intact. There could be more cases like this which can not be addressed by a single property setting.
The property "force.database.product.version=4.1" will only effect the functionality in question ... which is performance problems in the "information_schema" database. This is the simplest, lowest impact solution that solves the problem users have.
The property "force.database.product.version=4.1" will only effect the functionality in question ... which is performance problems in the "information_schema" database. This is the simplest, lowest impact solution that solves the problem users have.
Issue #6110 |
Closed |
Fixed |
Resolved |
Completion |
No due date |
Fixed Build 10.0.1 |
No time estimate |
Added handling of property force.database.product.version.
It will only accept a value formatted as x.y