LucidDbNonJavaClients

Introduction

The main client API for LucidDB is JDBC, which may not be terribly useful if you are developing an application in a language other than Java. This page discusses some options for overcoming this obstacle. None of these have been thoroughly tested yet, so experimental results are welcome.

PG2LucidDB

Alexander Mekhrishvili has built a middleware bridge from the PostgreSQL client to LucidDB, allowing access from any environment which already works with PostgreSQL (i.e. just about all of them). The announcement is here; you can get the code from code.google.com.

.net Integration

Alexander Mekhrishvili has also built an ADO.NET managed provider for use from .net on Windows and Mono on Linux. The announcement is here; you can get the code from code.google.com.

Command Line Invocation

The clumsiest integration would involve executing a sqllineClient process from the client application for each request, and then parsing the output. This is OK for batch jobs, but is unlikely to work very well for any kind of interactive application. CGI, anyone?

JVM Integration

Jython is a technology which allows you to integrate Java and Python in the same process. And zxJDBC bridges from Python's DB API to JDBC. So, if you are able to use Jython in your Python application, this should be a convenient way to call LucidDB via its JDBC driver (over either RMI or HTTP). You could even embed a LucidDB server JVM into your Python application and use the LucidDB local driver if you wanted to manage a single server process (similar to LucidDbAsManagedBean). The embedding approach may even allow you to flip it around and write a UDX in a language other than Java.

JRuby is like Jython, except it's for Ruby. Here's an example of using JDBC from within Ruby to call MySQL. And here is an ActiveRecord->JDBC bridge. And something similar for Sequel. DataObjects?

In Perl, there is always a way. Or more likely, about 60 different ways.

Http Calls

If your personal sense of language purity (or some more practical constraint) prevents you from integrating a JVM, you could study the internals of VJDBC used in HTTP mode (or just sniff the requests and responses). VJDBC actually serves as LucidDB's client/server JDBC implementation.

Alternatively, if you're looking for a higher level type HTTP access method (SOAP/REST xml/REST JSON) you should look at DynamoBI's AdminWS project that provides a bunch of query, browsing, and metadata operations on top of a LucidDB server.

Language Specific Remoting

If you can't integrate a JVM in your application, and HTTP is too much work, another option is to use a bridge server. Worst case, you would have to run three processes: your client application, a bridge server, and a LucidDB server. For example, the client application would run Ruby, the bridge server would JRuby, and the LucidDB server would run Java. Requests from the client application to the bridge server would go via an application-specific API to the bridge server using Ruby's own remoting, which would translate those into JDBC requests and call LucidDB via the remote JDBC driver.

This can be simplified by running only a single server process. In this example, it would run JRuby with LucidDB as an embedded engine (rather than LucidDB as a separate server), and would listen for the application-specific API calls and translate them into invocations on LucidDB's local JDBC driver.

Perhaps generic bridges like this already exist for your language of choice. For example, ODBC-to-JDBC bridges exist for C/C++ on Windows.

The Tungsten proxy from Continuent may also be an option (exposing a LucidDB server via MySQL client API's).