Try storing your connection in OptiqConnection.properties. Note that when you are passed a QueryProvider, it is usually safe to cast it to an OptiqConnection. YMMV.
It's not essential, but if your connections have a similar lifecycle to JDBC connections (i.e. expensive to create, may be re-used between statements, but may not be safe to use by more than one thread at a time), consider using a connection pool. Store your connection in a connection pool, add a wrapper whose close() method returns the connection to the pool, and make sure the client (i.e. the Optiq schema) calls close() when it's done. The connection pool will probably only need one connection if the concurrency is low. Julian On Jul 5, 2014, at 9:09 PM, Marc Prud’hommeaux <[email protected]> wrote: > Julian- > > My connection process is expensive, so I would like to keep the same > connection open for the lifespan of the JDBC Connection (i.e., I want to use > the same connection for schema querying as well as table enumeration). > However, SchemaFactory.create(SchemaPlus, String, Map) doesn't seem to give > me any access path to an OptiqConnection. How can I use the same connection > for the duration of the JDBC connection without storing it in my Schema > implementation? I notice that the mongodb driver holds onto the DB connection > in its own MongoSchema subclass. > > And yes, I am the original author of sqlline (as well as jline). I'm > delighted that you find it useful! > > -Marc > > On Jul 4, 2014, at 5:55 PM, Julian Hyde <[email protected]> wrote: > >> If you're working on a recent version of Optiq, schemas exist outside of >> connections. None of the objects in the schema (e.g. tables) should have a >> reference to an open connection. When you want to get data from these >> tables, an Optiq connection will be passed in. You can store the connection >> to the underlying system in the Optiq connection, or can create a connection >> for the duration of the scan, and make sure that you close it when the scan >> completes. >> >> See for example s.asQueryable. The Enumerator is from ResultSetEnumerable, >> which takes a DataSource as an argument, creates a java.sql.Connection, and >> calls java.sql.Connection.close() from ResultSetEnumerator.close(). >> >> While you are initializing a schema, you will probably create a short-lived >> connection, populate metadata, and then close the connection. >> JdbcSchema.computeTables is an example of this. The metadata objects (in >> this case instances of JdbcTable) do not keep a reference to that connection. >> >> Hope that helps. >> >> By the way, I presume you are the same Marc Prud'hommeaux who started the >> sqlline project many years ago. Thank you! We are still enjoying (and >> improving) that project. >> >> Julian >> >> On Jul 4, 2014, at 12:16 PM, Marc Prud’hommeaux <[email protected]> wrote: >> >>> Optiq Folk- >>> >>> I'm writing an Optiq adapter, modeled on the excellent optiq-csv sample. >>> I'm wondering when and where I should close the connection to the >>> underlying datasource? The connection is being created in my AbstractSchema >>> subclass, but there doesn't appear to be any close() or disconnect() method >>> in there for me to override. >>> >>> -Marc >>> >> >
