dbptk-developer
dbptk-developer copied to clipboard
keeps
How to specify connection properties?
Description: It is not clear from the documentation how connection properties like e.g. characterEncoding=UTF-8 (MySQL) should be configured. I guess it could be done using the generic jdbc import module and specifying a MySQL connection string like jdbc:mysql://localhost:3306?characterEncoding=UTF-8, but I would prefer to use the mysql module. Is this possible?
Thanks, Martin
OK, thanks! Is it planned? Or should indeed the jdbc import module be used for that?
It is not planned. But using the JDBC module to handle a mysql database will not work as good as the mysql module.
Maybe an additional parameter could exist that would force a specific connection string to be used, while still having to provide all the other parameters like database name and credentials.
Reopen: This is more important than I initially thought. It should be possible to specify JDBC URL parameters because otherwise in some cases data loss cannot be avoided, see issue #323.
Hi @marhop, would you up to create a fix for this issue on a pull request? The main point to change is this line: https://github.com/keeps/db-preservation-toolkit/blob/master/dbptk-modules/dbptk-module-mysql/src/main/java/com/databasepreservation/modules/mySql/in/MySQLJDBCImportModule.java#L52
And then fix all things that break due to that change.
OK, I'll see what I can do. I fear I can't promise to deliver something in the next few weeks though because I am a little short on time at the moment. So if anybody else is in a hurry, go ahead!
How would you prefer to include this in the command line interface? Allow users to specify arbitrary JDBC URLs (like SIARD Suite 2 does), or add a new command line option like --import-configuration-property (more in line with the existing dbptk interface)?
I think a command line options would be more adequate. Actually this should be a convention for all models that use JDBC underneath. Part of the JDBC connection string might need to be controlled by the module that connects, as it might be needed to enable a correct conversion of information. Other parts could be optional and used case to case.
Another option would be not to allow changes in the JDBC connection string but add a specific option for the features required, like defining the connection encoding or how defining how columns of type bit are parsed. Problem of this approach would be the lack of flexibility as every new case might need a new flag to be added, on the other hand it will spare the common user of knowing about the inner working of JDBC to be able to correctly export information for a database.
A third option would be to support both, JDBC connection string override and flag for specific optional features, this may please both expert and less technical users, but will also be more work to develop.