Both Talend (Java) and Kettle distribute the Zentus.com pure-Java SQLite JDBC driver and for most purposes this run-anywhere version is fine. But, if you really need to take advantage of SQLite’s speed then connecting using the native JNI version is a must. Doing this was easy enough, just change over to using a generic JDBC connection specifying the required native jar and placing the associated dll/so on your system path.
But now there’s an easier way, the latest version (V052, in fact from V050 on) is a universal jar, it contains native JNI libraries for Windows, Linux and MacOS alongside the pure-Java version. It will automatically pick the correct lib for the platform and fall back to the pure-Java version if required. You can tell if it’s picked up the native lib by calling conn.getDriverVersion(); it’ll return “native” if it has.
To upgrade to this jar in Kettle see this, this time replacing the nested jar with sqlitejdbc-v052.jar.
- Either rename the new V052 jar to sqlitejdbc_v037_nested.jar, replace the existing V037 jar in the ../lib/java folder with this new renamed file.
- Or, you could edit the Java specific XML files in the various tSQlite component folders, replacing the references to the old nested V037 jar.
- Or, and this is what I would do, don’t use the tSQLite components, replace them with tJDBC generic components, then you can pick whatever version of the driver you require, you could even change to a different database provider!
The Talend tradition of a separate set of components for each type of database, seems to be a hangover from its Perl-generating roots. It’s true that database specific components are required for certaing tasks such as bulk-loading, ELTs and so on, but JDBC was designed to be generic and as long as the SQL syntax is compatible, it makes switching in an out database providers very easy. So unless there’s a good reason, stick to using tJDBC.