Similarly, we're also currently considering how best to implement some of the SQL standard session variables in our Flight SQL server - things like current transaction isolation level, access mode, time zone etc, which seem to have similar properties to the (traditional) connection's current catalog. We'd (perhaps naively) looked at solutions involving the Flight client's `ClientCookieMiddleware`, but might these have standardised support within Flight SQL itself eventually?
Cheers, James On Wed, 9 Nov 2022 at 21:51, David Li <lidav...@apache.org> wrote: > I think having better support for this makes sense, but perhaps we can > find a way to make it not tied to the connection itself? For instance, in > the same way transactions were implemented (as a handle). Or rather, > instead of adding connection statefulness to Flight RPC, I'd rather try to > work within the gRPC/RPC paradigm. > > On Wed, Nov 9, 2022, at 16:47, James Duong wrote: > > Databases such as SQL Server and PostgreSQL have the concept of catalogs > as > > containers of database schemas. Users can usually specify an initial > > catalog during the connection process, list catalogs, and sometimes > change > > catalogs during the session. > > > > Currently catalog support in Flight SQL is somewhat limited. The protocol > > provides a way to list catalogs as well as metadata in SqlTypeInfo for > > reporting how catalogs are supported from a syntax perspective. > > > > ODBC and JDBC provide API calls for changing the catalog. Additionally, > > Flight SQL doesn't really provide the concept of "initial" connection > > properties (such as a starting catalog) since Flight itself is stateless > > from a connection perspective. > > > > To support catalogs properly, I'd imagine we need to make some changes to > > the Flight SQL protocol: > > - Introduce the concept of connection-time properties (perhaps an > optional > > RPC for Flight SQL applications that need this) > > - Related to the above, expand the connection URL and Java builder to > allow > > arbitrary application-specific properties. > > - Add optional RPCs for changing the catalog and relevant error codes if > > this is not permitted. > > > > > > -- > > > > *James Duong* > > Lead Software Developer > > Bit Quill Technologies Inc. > > Direct: +1.604.562.6082 | jam...@bitquilltech.com > > https://www.bitquilltech.com > > > > This email message is for the sole use of the intended recipient(s) and > may > > contain confidential and privileged information. Any unauthorized > review, > > use, disclosure, or distribution is prohibited. If you are not the > > intended recipient, please contact the sender by reply email and destroy > > all copies of the original message. Thank you. > -- *James Henderson* XTDB Developer at *JUXT* Email j...@juxt.pro Website https://juxt.pro [image: photo]
