[jira] [Comment Edited] (CALCITE-522) In remote JDBC driver, transmit static database properties as a map

["Julian Hyde (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CALCITE-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14500591#comment-14500591 ] 

Julian Hyde edited comment on CALCITE-522 at 4/17/15 8:22 PM:
--------------------------------------------------------------

I was thinking of making a call that has no parameters and returns a Map<Property, Object> of all properties whose value is not equal to the default. (The default is defined in the Property enum, and therefore is available both client and server side.)

That map can then be cached, so the request only needs to be made once.

Fine to deprecate methods, but you need to provide a comment when they will be removed. Generally '// will be removed before 2.0'. In this case, since Avatica is still experimental, I think you can just remove them. But just mention that they've been removed in the commit comment. [~ndimiduk], do you agree?

Rename PropertyName to DatabaseProperty. ("Name" implies string.)

I don't think you need class DatabaseProperty. You can just return a map, right? The value in the map should be an Object (albeit a simple one that is JSON-serializable) not a String.

I don't tend to supply the message argument (e.g. "Fail to get SYSTEM_FUNCTIONS") to assertEquals. In fact I would write {code}assertThat(connection.getMetaData().getSystemFunctions(),
    is("DATABASE,IFNULL,USER"));{code} but it's a matter of personal preference.


was (Author: julianhyde):
I was thinking of making a call that has no parameters and returns a Map<Property, Object> of all properties whose value is not equal to the default. (The default is defined in the Property enum, and therefore is available both client and server side.)

That map can then be cached, so the request only needs to be made once.

Fine to deprecate methods, but you need to provide a comment when they will be removed. Generally '// will be removed before 2.0'. In this case, since Avatica is still experimental, I think you can just remove them. But just mention that they've been removed in the commit comment. [~ndimiduk], do you agree?

Rename PropertyName to DatabaseProperty. ("Name" implies string.)

I don't think you need class DatabaseProperty. You can just return a map, right? The value in the map should be an Object (albeit a simple one that is JSON-serializable) not a String.

I don't tend to supply the message argument (e.g. "Fail to get SYSTEM_FUNCTIONS") to assertEquals. In fact I would write {code}assertThat(connection.getMetaData().getSystemFunctions()
  is("DATABASE,IFNULL,USER"));{code} but it's a matter of personal preference.

> In remote JDBC driver, transmit static database properties as a map
> -------------------------------------------------------------------
>
>                 Key: CALCITE-522
>                 URL: https://issues.apache.org/jira/browse/CALCITE-522
>             Project: Calcite
>          Issue Type: Bug
>            Reporter: Julian Hyde
>            Assignee: Julian Hyde
>
> A lot of DatabaseMetaData methods are not parameterized, and give the same answer every time. Some examples:
> * allProceduresAreCallable
> * getUserName
> * isReadOnly
> * getDatabaseProductName
> * getDatabaseProductVersion
> * getDriverName
> * getDriverVersion
> * getDriverMajorVersion
> * getDriverMinorVersion
> * getSqlKeywords
> * getNumericFunctions
> * getStringFunctions
> * getSystemFunctions
> * getTimeDateFunctions
> This task would define an enum of properties, add a method to Meta that returns (property, value) map.
> See DatabaseMetaData and Connection for the full list.
> Obsolete the following Meta methods:
> * getSqlKeywords
> * getNumericFunctions
> * getStringFunctions
> * getSystemFunctions
> * getTimeDateFunctions



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)