SqlLite interface from java?

    Oct 07 2008 | 7:20 pm
    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)

    • Oct 16 2008 | 3:40 pm
      Hmmm.. this looks promising : http://www.zentus.com/sqlitejdbc/
      a li'l embarrassed, char lieb
      on glorious five days away from property insurance!!! l&k always......
    • Oct 16 2008 | 6:25 pm
      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.
    • Oct 23 2008 | 2:06 pm
      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.
      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 javaScript (included in Max5)
      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.
      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...)
      Char lieB
    • Oct 23 2008 | 3:36 pm
      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 (http://db.apache.org/derby/ ) alongside HSQLDB, but so far haven't seen any need to move away from the latter.
      -- N.
      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