Re: [sqlite] RE: [RBL] Re: [sqlite] Sqlite and Java

[John Stanton]

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.

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