Thank you Dmitry. Responses inline.



On 4/20/15, 7:09 AM, "Dmitriy Setrakyan" <[email protected]> wrote:

>On Mon, Apr 20, 2015 at 8:31 AM, Ram Venkatesh <[email protected]>
>wrote:
>
>> Hi Eran,
>>
>> Good idea, maybe we can create a base JdbcInterpreter class and have
>> implementations like HiveInterpreter, OtherInterpreter for specific
>> functionality (for example the Hive interpreter logic for progress is going
>> to be Hive specific). This will let us implement connection pooling, fatal
>> error detection, result set composition etc. in a common manner.
>>
>
>Does Zepelling need any write-capabilities for JDBC driver? I personally
>think No, but just confirming. Apache Ignite, for example, only provides
>read-only JDBC connectivity.

Zeppelin itself does not mandate what features need to be supported. Providing 
read-only access is a great start IMO.
However, write capabilities might make it convenient to for data scientists who 
want to clean the data a bit or work with intermediate results.

>
>
>>
>> Another proposal: instead of %sql implying SparkSql, given sql access
>> seems to be popular should we change that interpreter directive to
>>
>> %sparksql
>> %hiveql
>> …
>>
>> This would make it clear to the user what dialect / subset of SQL is
>> appropriate for which note. If others also think this is useful I would
>> like to do it asap since it affects end users.
>>
>
>Sounds like a great idea.

Cool - will open a ticket for this change.

>
>
>>
>>
>> Ram
>>
>> On 4/19/15, 11:13 PM, "IT CTO" <[email protected]> wrote:
>>
>> >Hi,
>> >I read the thread about the new Tajo interpreter and the thread about
>> >Apache Ignite, and while browsing through the code of the Hive interpreter
>> >I realized that for all of the JDBC based interpreters the implementation
>> >should be very much the same.
>> >
>> >Should we implement a generic JDBC interpreter with properties in the
>> >interpreter page to set the driver name as well as the url, user and
>> >password?
>> >
>> >One thing that I don't know how to solve is the ability to use two
>> >difference JDBC interpreters together but I am not sure if that needed.
>> >
>> >Any feedback is appreciated...
>> >Eran
>>

Reply via email to