Re: RE: RE: AW: AW: [sqlite] New JDBC driver for SQLite
Brannon wrote: It was just a warning. Instructions for MSVC added to the README.
RE: RE: AW: AW: [sqlite] New JDBC driver for SQLite
> Thanks for the info. Points 2, 4 and 5 are covered by the > Makefile (DB.h is generated with javah), but I'll patch the > project for the variable declarations and the cast. Though I > have a feeling the cast is unncessesary, did VC throw an > error or warning for that? It was just a warning.
Re: RE: AW: AW: [sqlite] New JDBC driver for SQLite
Brannon King wrote: To compile the binary with VC71, I had to 1. move a dozen variable declarations to the top of the function 2. download the DB.h file separately from the build tree 3. change the jstrlen to end with "return (int)(s - str) - suppChars" 4. change my sqlite3 lib build to #define SQLITE_ENABLE_COLUMN_METADATA 5. reference the sqlite3 lib in a dll project containing the DB.c/h Thanks for the info. Points 2, 4 and 5 are covered by the Makefile (DB.h is generated with javah), but I'll patch the project for the variable declarations and the cast. Though I have a feeling the cast is unncessesary, did VC throw an error or warning for that? I'd be interested in knowing if you've noticed a significant speed improvement. The simplest test would be running test.Test from the source tree. d
RE: AW: AW: [sqlite] New JDBC driver for SQLite
To compile the binary with VC71, I had to 1. move a dozen variable declarations to the top of the function 2. download the DB.h file separately from the build tree 3. change the jstrlen to end with "return (int)(s - str) - suppChars" 4. change my sqlite3 lib build to #define SQLITE_ENABLE_COLUMN_METADATA 5. reference the sqlite3 lib in a dll project containing the DB.c/h > -Original Message- > From: David Crawshaw [mailto:[EMAIL PROTECTED] > Sent: Monday, July 31, 2006 2:03 AM > To: Martin Pfeifle; sqlite-users@sqlite.org > Subject: Re: AW: AW: [sqlite] New JDBC driver for SQLite > > Martin Pfeifle wrote: > > could you please shortly outline the differences between your jdbc > > driver and the one developed by Christian Werner? > > I haven't looked too closely at the other driver, but from > what I have seen, it is designed to work with the old > callback exec() functions, so it supports SQLite 2, but is > probably slower. > > I've gone for simplicity with this one. This driver has a lot > less code in it. There is a single .c file: > > http://java.zentus.com/src/sqlitejdbc/src/org/sqlite/DB.java > http://java.zentus.com/src/sqlitejdbc/src/org/sqlite/DB.c > > which basically maps the C functions into Java. The JDBC > implementation just calls these functions as appropriate. > > I also put a lot of effort into making binaries, so it is easy to use. > Compiling JNI libraries for different platforms is a bit of a pain. > > d >
Re: AW: AW: [sqlite] New JDBC driver for SQLite
Martin Pfeifle wrote: could you please shortly outline the differences between your jdbc driver and the one developed by Christian Werner? I haven't looked too closely at the other driver, but from what I have seen, it is designed to work with the old callback exec() functions, so it supports SQLite 2, but is probably slower. I've gone for simplicity with this one. This driver has a lot less code in it. There is a single .c file: http://java.zentus.com/src/sqlitejdbc/src/org/sqlite/DB.java http://java.zentus.com/src/sqlitejdbc/src/org/sqlite/DB.c which basically maps the C functions into Java. The JDBC implementation just calls these functions as appropriate. I also put a lot of effort into making binaries, so it is easy to use. Compiling JNI libraries for different platforms is a bit of a pain. d
AW: AW: [sqlite] New JDBC driver for SQLite
Hi David, could you please shortly outline the differences between your jdbc driver and the one developed by Christian Werner? Best Martin - Ursprüngliche Mail Von: David Crawshaw <[EMAIL PROTECTED]> An: sqlite-users@sqlite.org; Martin Pfeifle <[EMAIL PROTECTED]> Gesendet: Sonntag, den 30. Juli 2006, 23:37:17 Uhr Betreff: Re: AW: [sqlite] New JDBC driver for SQLite Martin Pfeifle <[EMAIL PROTECTED]> wrote: > Does the jdbc driver also provide the direct reading and writing of BLOBs? Yes, through PreparedStatement.setBytes() and ResultSet.getBytes(). I haven't added support yet for the java.sql.Blob type, because I am funadmentally opposed to the idea of SQL calls generating heap garbage and invoking the GC. One thing I am trying to solve is how to get the size of a BLOB without using RS.getBLOB(). d
Re: AW: [sqlite] New JDBC driver for SQLite
Martin Pfeifle <[EMAIL PROTECTED]> wrote: Does the jdbc driver also provide the direct reading and writing of BLOBs? Yes, through PreparedStatement.setBytes() and ResultSet.getBytes(). I haven't added support yet for the java.sql.Blob type, because I am funadmentally opposed to the idea of SQL calls generating heap garbage and invoking the GC. One thing I am trying to solve is how to get the size of a BLOB without using RS.getBLOB(). d
AW: [sqlite] New JDBC driver for SQLite
Does the jdbc driver also provide the direct reading and writing of BLOBs?
Best Matin
- Ursprüngliche Mail
Von: David Crawshaw <[EMAIL PROTECTED]>
An: sqlite-users@sqlite.org
Gesendet: Sonntag, den 30. Juli 2006, 14:56:18 Uhr
Betreff: [sqlite] New JDBC driver for SQLite
Hello all,
I have written a new JDBC driver for SQLite.
http://java.zentus.com/sqlitejdbc.html
It is designed to be easy to read and as thin a layer as possible on
top of the C functions. The new _prepare()/_step() API is surprisingly
similar to the JDBC API, making it efficient code. SQLite is compiled
straight into the JNI binary, which keeps things simple for Java
programmers. There is only one dll/so/jnilib that needs to be added to
a project.
I've build binaries for Linux i386, Mac (universal) and Windows. Any
testing would be greatly appreciated, I don't have much hardware.
My few speed tests so far suggest it is fast. Code like:
statement.setAutoCommit(false);
for (int i=0; i < 1000; i++)
statement.executeUpdate("INSERT INTO...");
statement.commit();
runs in under 30ms on Linux. This means the JNI bridge is not causing
any serious overhead.
There are still a couple of features to add. I plan automatic Java
date/time handling and the code is not thread safe. These are not
difficult to do, I am just distracted by another optimisation right
now.
The code is under the BSD license. I hope someone finds a use for it.
d
