Re: [sqlite] RE: [RBL] Re: [sqlite] Sqlite and Java
Fred makes a good point. A well conceived software solution is a good investment and a slipshod, makeshift solution not an investment but an ongoing liability. We have some software which was carefully thought through initially and has been in constant national use for close to twenty years again on generation after generation of hardware, simply because the problem did not change. Surely one's clients deserve to have their money spent prudently in the spirit of "If you don't have time to do it right you don't have time to do it twice". I would expect that some of the Sqlite applications being developed today will have an inherent simplicity and direct function such that they will also be functioning in decades hence despite fashion changes and hardware advances. Sqlite follows Einstein's view "Make it as simple as possible but no simpler". JS Fred Williams wrote: You points are understood. But I've always attempted to use a hammer for a nail and a screwdriver for a screw. This extra effort always produces a much cleaner and professional result. Good clients know that response time is money and resources they spend every day and at every seat. Proper software development is a high cost one time event. I have had occasion to see code I have written running five plus years after implementation. In that time migrated across three platforms. Fred -Original Message- From: Steve O'Hara [mailto:[EMAIL PROTECTED] Sent: Sunday, January 22, 2006 4:06 AM To: sqlite-users@sqlite.org Subject: RE: [sqlite] RE: [RBL] Re: [sqlite] Sqlite and Java You're right to a certain extent, but the point I was trying to address was the ideal of being able to use an SQLite database from a variety of toolsets and environments natively. If you've ever written JNI you'll know why this is a pain and a Java only implementation would be sweet. Also, not all SQL engines work the same way and I'm certain HSQLD is slower than SQLite architecturally, not because it's implemented in Java. After all, there is a non-free variant of HSQLDB (HyperXtremSQL) written in Java by the same author that is 50% faster - he didn't get that by tweaking the code, more like re-architecting the storage. The language is just a tool, a way of describing a solution to a machine. The judgement of performance etc of a language is a little specious because it implies a generalisation of how the language is implemented on a particular platform. I've learned to like Java because I've got a beautiful development environment (intelliJ IDEA) and in my professional life, speed/quality of development is more important than response times. My clients would prefer to spend more money on hardware than on consultancy - who can blame them. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:sqlite-users-return-10034-sohara=pivotal-solutions.co. [EMAIL PROTECTED] org] On Behalf Of Fred Williams Sent: 21 January 2006 15:52 To: sqlite-users@sqlite.org Subject: RE: [sqlite] RE: [RBL] Re: [sqlite] Sqlite and Java I think if you will closely read you own analysis of your efforts you will realize that all of the "down side" issues you have enumerated relate directly to the implementation language and not the database or its structure. In Java there is no such thing as AnythingLite, IMHO. Java, like so many other languages has grown well beyond its initial intent, small, simple applets imbedded on a web page. With all of our advances in programming we still have not evolved that "perfect" language, and most likely never will. I spite of what those "C" guys tell you :-) Fred -Original Message- From: Steve O'Hara [mailto:[EMAIL PROTECTED] Sent: Saturday, January 21, 2006 7:37 AM To: sqlite-users@sqlite.org; [EMAIL PROTECTED] Subject: [sqlite] RE: [RBL] Re: [sqlite] Sqlite and Java I did loads of research on this and even tinkered with a c to Java converter, which got me a little bit further forward. However, I realised that I would be facing a huge effort to create the code base and then have to support it within our projects. So despite being an SQLite zealot, I had to reluctantly nail my colours to one of the existing Java tools. I chose HSQLDB, after trying out most of the others, this was the only one that got close to the file distribution format of SQLite i.e. database in a file. It took quite a bit of tinkering to get the right mix of CACHED and MEMORY tables so that performance on start-up was good. Also, I had terrible trouble with mass imports causing memory (what a surprise - Java) problems and it took a good few runs to get it to properly index etc. Also, I had to be much more specific about the column definitions than with SQLite, otherwise my database files grew horribly. Also, you can only interact with HSQLDB via JDBC, not a big problem in Java obviously. Performance was nowhere near as good as SQLite.
RE: [sqlite] RE: [RBL] Re: [sqlite] Sqlite and Java
You points are understood. But I've always attempted to use a hammer for a nail and a screwdriver for a screw. This extra effort always produces a much cleaner and professional result. Good clients know that response time is money and resources they spend every day and at every seat. Proper software development is a high cost one time event. I have had occasion to see code I have written running five plus years after implementation. In that time migrated across three platforms. Fred > -Original Message- > From: Steve O'Hara [mailto:[EMAIL PROTECTED] > Sent: Sunday, January 22, 2006 4:06 AM > To: sqlite-users@sqlite.org > Subject: RE: [sqlite] RE: [RBL] Re: [sqlite] Sqlite and Java > > > You're right to a certain extent, but the point I was trying > to address > was the ideal of being able to use an SQLite database from a > variety of > toolsets and environments natively. If you've ever written JNI you'll > know why this is a pain and a Java only implementation would be sweet. > > Also, not all SQL engines work the same way and I'm certain HSQLD is > slower than SQLite architecturally, not because it's implemented in > Java. After all, there is a non-free variant of HSQLDB > (HyperXtremSQL) > written in Java by the same author that is 50% faster - he didn't get > that by tweaking the code, more like re-architecting the storage. > > The language is just a tool, a way of describing a solution to a > machine. The judgement of performance etc of a language is a little > specious because it implies a generalisation of how the language is > implemented on a particular platform. I've learned to like > Java because > I've got a beautiful development environment (intelliJ IDEA) and in my > professional life, speed/quality of development is more important than > response times. My clients would prefer to spend more money > on hardware > than on consultancy - who can blame them. > > Steve > > -Original Message- > From: > [EMAIL PROTECTED] > [mailto:sqlite-users-return-10034-sohara=pivotal-solutions.co. > [EMAIL PROTECTED] > org] On Behalf Of Fred Williams > Sent: 21 January 2006 15:52 > To: sqlite-users@sqlite.org > Subject: RE: [sqlite] RE: [RBL] Re: [sqlite] Sqlite and Java > > I think if you will closely read you own analysis of your efforts you > will realize that all of the "down side" issues you have enumerated > relate directly to the implementation language and not the database or > its structure. In Java there is no such thing as AnythingLite, IMHO. > Java, like so many other languages has grown well beyond its initial > intent, small, simple applets imbedded on a web page. > > With all of our advances in programming we still have not evolved that > "perfect" language, and most likely never will. I spite of what those > "C" guys tell you :-) > > Fred > > > -----Original Message- > > From: Steve O'Hara [mailto:[EMAIL PROTECTED] > > Sent: Saturday, January 21, 2006 7:37 AM > > To: sqlite-users@sqlite.org; [EMAIL PROTECTED] > > Subject: [sqlite] RE: [RBL] Re: [sqlite] Sqlite and Java > > > > > > > > I did loads of research on this and even tinkered with a c to Java > > converter, which got me a little bit further forward. However, I > > realised that I would be facing a huge effort to create the > code base > > and then have to support it within our projects. So > despite being an > > SQLite zealot, I had to reluctantly nail my colours to one of the > > existing Java tools. > > > > I chose HSQLDB, after trying out most of the others, this > was the only > > one that got close to the file distribution format of SQLite i.e. > > database in a file. It took quite a bit of tinkering to > get the right > > mix of CACHED and MEMORY tables so that performance on start-up was > > good. Also, I had terrible trouble with mass imports causing memory > > (what a surprise - Java) problems and it took a good few runs > > to get it > > to properly index etc. Also, I had to be much more > specific about the > > column definitions than with SQLite, otherwise my database > files grew > > horribly. Also, you can only interact with HSQLDB via > JDBC, not a big > > problem in Java obviously. Performance was nowhere near as good as > > SQLite. > > > > However, the upside is that HSQLDB is free, simple to deploy, has > > standalone/server/servlet/in-memory deployment versions and is > > reasonably perfomant. > > > > Hope this helps, > > > > Steve > > > > p.s. I'd still prefer a Java SQLite but there you are > > > > > > > > -
RE: [sqlite] RE: [RBL] Re: [sqlite] Sqlite and Java
You're right to a certain extent, but the point I was trying to address was the ideal of being able to use an SQLite database from a variety of toolsets and environments natively. If you've ever written JNI you'll know why this is a pain and a Java only implementation would be sweet. Also, not all SQL engines work the same way and I'm certain HSQLD is slower than SQLite architecturally, not because it's implemented in Java. After all, there is a non-free variant of HSQLDB (HyperXtremSQL) written in Java by the same author that is 50% faster - he didn't get that by tweaking the code, more like re-architecting the storage. The language is just a tool, a way of describing a solution to a machine. The judgement of performance etc of a language is a little specious because it implies a generalisation of how the language is implemented on a particular platform. I've learned to like Java because I've got a beautiful development environment (intelliJ IDEA) and in my professional life, speed/quality of development is more important than response times. My clients would prefer to spend more money on hardware than on consultancy - who can blame them. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of Fred Williams Sent: 21 January 2006 15:52 To: sqlite-users@sqlite.org Subject: RE: [sqlite] RE: [RBL] Re: [sqlite] Sqlite and Java I think if you will closely read you own analysis of your efforts you will realize that all of the "down side" issues you have enumerated relate directly to the implementation language and not the database or its structure. In Java there is no such thing as AnythingLite, IMHO. Java, like so many other languages has grown well beyond its initial intent, small, simple applets imbedded on a web page. With all of our advances in programming we still have not evolved that "perfect" language, and most likely never will. I spite of what those "C" guys tell you :-) Fred > -Original Message- > From: Steve O'Hara [mailto:[EMAIL PROTECTED] > Sent: Saturday, January 21, 2006 7:37 AM > To: sqlite-users@sqlite.org; [EMAIL PROTECTED] > Subject: [sqlite] RE: [RBL] Re: [sqlite] Sqlite and Java > > > > I did loads of research on this and even tinkered with a c to Java > converter, which got me a little bit further forward. However, I > realised that I would be facing a huge effort to create the code base > and then have to support it within our projects. So despite being an > SQLite zealot, I had to reluctantly nail my colours to one of the > existing Java tools. > > I chose HSQLDB, after trying out most of the others, this was the only > one that got close to the file distribution format of SQLite i.e. > database in a file. It took quite a bit of tinkering to get the right > mix of CACHED and MEMORY tables so that performance on start-up was > good. Also, I had terrible trouble with mass imports causing memory > (what a surprise - Java) problems and it took a good few runs > to get it > to properly index etc. Also, I had to be much more specific about the > column definitions than with SQLite, otherwise my database files grew > horribly. Also, you can only interact with HSQLDB via JDBC, not a big > problem in Java obviously. Performance was nowhere near as good as > SQLite. > > However, the upside is that HSQLDB is free, simple to deploy, has > standalone/server/servlet/in-memory deployment versions and is > reasonably perfomant. > > Hope this helps, > > Steve > > p.s. I'd still prefer a Java SQLite but there you are > > > > -Original Message- > From: > [EMAIL PROTECTED] > [mailto:sqlite-users-return-9982-sohara=pivotal-solutions.co.u [EMAIL PROTECTED] rg] On Behalf Of Ran Sent: 19 January 2006 14:13 To: sqlite-users@sqlite.org; [EMAIL PROTECTED] Subject: [RBL] Re: [sqlite] Sqlite and Java If I am not mistaken, the following thread might be relevant: http://www.mail-archive.com/sqlite-users@sqlite.org/msg11005.html Ran On 1/19/06, Nilo Paim <[EMAIL PROTECTED]> wrote: > > Hi all, > > Does anybody here knows something about a port of sqlite to java? > > Please, note that I'm not talking about java calling sqlite via JNI, but > about a real rewrite of sqlite using java. Obviously, a second step > would be the writing of a JDBC driver. > > Would be useful that port? > > Comments? Suggestions? > > Thanks to all. > > Nilo > Porto Alegre - Brasil >
RE: [sqlite] RE: [RBL] Re: [sqlite] Sqlite and Java
I think if you will closely read you own analysis of your efforts you will realize that all of the "down side" issues you have enumerated relate directly to the implementation language and not the database or its structure. In Java there is no such thing as AnythingLite, IMHO. Java, like so many other languages has grown well beyond its initial intent, small, simple applets imbedded on a web page. With all of our advances in programming we still have not evolved that "perfect" language, and most likely never will. I spite of what those "C" guys tell you :-) Fred > -Original Message- > From: Steve O'Hara [mailto:[EMAIL PROTECTED] > Sent: Saturday, January 21, 2006 7:37 AM > To: sqlite-users@sqlite.org; [EMAIL PROTECTED] > Subject: [sqlite] RE: [RBL] Re: [sqlite] Sqlite and Java > > > > I did loads of research on this and even tinkered with a c to Java > converter, which got me a little bit further forward. However, I > realised that I would be facing a huge effort to create the code base > and then have to support it within our projects. So despite being an > SQLite zealot, I had to reluctantly nail my colours to one of the > existing Java tools. > > I chose HSQLDB, after trying out most of the others, this was the only > one that got close to the file distribution format of SQLite i.e. > database in a file. It took quite a bit of tinkering to get the right > mix of CACHED and MEMORY tables so that performance on start-up was > good. Also, I had terrible trouble with mass imports causing memory > (what a surprise - Java) problems and it took a good few runs > to get it > to properly index etc. Also, I had to be much more specific about the > column definitions than with SQLite, otherwise my database files grew > horribly. Also, you can only interact with HSQLDB via JDBC, not a big > problem in Java obviously. Performance was nowhere near as good as > SQLite. > > However, the upside is that HSQLDB is free, simple to deploy, has > standalone/server/servlet/in-memory deployment versions and is > reasonably perfomant. > > Hope this helps, > > Steve > > p.s. I'd still prefer a Java SQLite but there you are > > > > -Original Message- > From: > [EMAIL PROTECTED] > [mailto:sqlite-users-return-9982-sohara=pivotal-solutions.co.u [EMAIL PROTECTED] rg] On Behalf Of Ran Sent: 19 January 2006 14:13 To: sqlite-users@sqlite.org; [EMAIL PROTECTED] Subject: [RBL] Re: [sqlite] Sqlite and Java If I am not mistaken, the following thread might be relevant: http://www.mail-archive.com/sqlite-users@sqlite.org/msg11005.html Ran On 1/19/06, Nilo Paim <[EMAIL PROTECTED]> wrote: > > Hi all, > > Does anybody here knows something about a port of sqlite to java? > > Please, note that I'm not talking about java calling sqlite via JNI, but > about a real rewrite of sqlite using java. Obviously, a second step > would be the writing of a JDBC driver. > > Would be useful that port? > > Comments? Suggestions? > > Thanks to all. > > Nilo > Porto Alegre - Brasil >
