Charles Baker

Are there Java bindings for the C++ embedded SqlLite code in Max? use JCom, perhaps?

Javascript is cool, but Java is cooler, and although there are java embedded dbms (thx, NickR. for your implementation of hsqldb), if the app that mxj is called from has an embedded DB already, why do we need another? occam's razor, etc.? Would a com style call be so very much overhead, compared to an entire additional embedded DBMS?

Folks-
Are there Java bindings for the C++ embedded SqlLite code in Max? use JCom, perhaps?
Javascript is cool, but Java is cooler, and although there are java embedded dbms (thx, NickR. for your implementation of hsqldb), if the app that mxj is called from has an embedded DB already, why do we need another? occam's razor, etc.? Would a com style call be so very much overhead, compared to an entire additional embedded DBMS?

thanks
Charlie B., Ph.D.
baker@charlieb.com
850-212-2121 (c)

Production Development Support
Citizens Property Insurance Corporation
of Florida
cbaker@citizensfla.com
850-513-3876 (w)


sqllite-interface-from-java

on glorious five days away from property insurance!!!

Hmmm.. this looks promising : http://www.zentus.com/sqlitejdbc/

on glorious five days away from property insurance!!!
l&k always......


Quote: Charles Baker wrote on Thu, 16 October 2008 08:40

----------------------------------------------------

Interesting. Let us know how things turn out.

Quote: Charles Baker wrote on Thu, 16 October 2008 08:40
----------------------------------------------------
> Hmmm.. this looks promising : http://www.zentus.com/sqlitejdbc/
>

Interesting. Let us know how things turn out.


the running sqllite instance is separate from the memory image in the js interpreter: they have different persistence locations

(the files are saved in different places), but the saved files are compatible.

It seems clear that the two implementation (the js interpreter and the jvm/jdbc version) are each using their own running memory images... there can only be one connection to each at any given time, but both implementations can be running at the same time, even accessing db's named the same, and the data in memory is not effected by the other. the persisted file is saved in a different locationin JS than JVM. Two or more connections to same db in java or two connections to db in js won't work, one connection per memory instance.

The HSQLDB implementation is very fast, and has a *much* larger set of SQL implememnted, including granting privilages, full implementation unions and joins, and other nicities.

That being said one might use the java/jdbc SqlLite implementation over the HSQLDB implementation just for the file compatibility: there is not much one would want to do in a Max App that the SqlLiteLDBC can't do. And therefore, unless there is a need for Java extensibility, the javascript version should be fine.

So, three embedded DB choices, all good, all with strengths, but one is a much fuller implementation of SQL.

SqlLite in JVM - like the JS version, but embedded in the larger, more fully developed Java language.

HSQLDB in JVM - most fully implemented of the choices , by far.

Only issue would be non -compatibility with the Max5 embedded SqlLite's persisted files.

The last two (w/ DBs embedded in JVM's, not javascript interpreter) seem to work just fine in Max4.6.

(as the old lady said as she kissed the cow...)

the sqllitejdbc works great in java, 
the running sqllite instance is separate from the memory image in the js interpreter: they have different persistence locations
(the files are saved in different places), but the saved files are compatible.
It seems clear that the two implementation (the js interpreter and the jvm/jdbc version) are each using their own running memory images... there can only be one connection to each at any given time, but both implementations can be running at the same time, even accessing db's named the same, and the data in memory is not effected by the other. the persisted file is saved in a different locationin JS than JVM. Two or more connections to same db in java or two connections to db in js won't work, one connection per memory instance.

SqlLite in javaScript 
(included in Max5)

HSQLDB in JVM - most fully implemented of the choices , by far.
Only issue would be non -compatibility with the Max5 embedded SqlLite's persisted files.

and finally:
The last two (w/ DBs embedded in JVM's, not javascript interpreter) seem to work just fine in Max4.6.

Lotsa choice, it's all good,
 "Chacun a son Gout" 
(as the old lady said as she kissed the cow...)

On 23 Oct 2008, at 15:06, Charles Baker wrote:

> HSQLDB in JVM - most fully implemented of the choices , by far.

FWIW, I also implemented support for the Derby DB (

) alongside HSQLDB, but so far haven't seen any need to move away 

FWIW, I also implemented support for the Derby DB (http://db.apache.org/derby/ 
) alongside HSQLDB,  but so far haven't seen any need to move away  
from the latter.

Nick Rothwell / Cassiel.com Limited
www.cassiel.com
www.myspace.com/cassieldotcom
www.last.fm/music/cassiel
www.reverbnation.com/cassiel
www.linkedin.com/in/cassiel
www.loadbang.net


SqlLite interface from java?