I agree with your idea and +1 to create one interpreter setting for each database. 2017년 5월 24일 (수) 오후 3:45, Jeff Zhang <zjf...@gmail.com>님이 작성:
> The current JdbcInterpreter implementation seems too generic for me. > Two main reasons > > 1. The logic of executing sql in JdbcInterpeter is a little weird. Here's > is what jdbc interpreter would do for "%jdbc(mysql) show tables" > The script part is actually `(mysql) show tables` rather than `show > tables`, jdbc interpreter first parse it to get property key `mysql` then > execute sql `show tables` for mysql. This is kind weird to do parsing in > jdbc interpreter. I would use '%jdbc(mysql)' as interpreter name part, > `mysql` could be some kind of interpreter property, but never to make > interpreter to do parsing again. 'show tables' should be the sql script > part which is sent to jdbc interpreter. Doing specific parsing in > interpreter is not a good practise IMHO. This also make the parsing > repl/script logic a little weird in Paragraph.java > > 2. All the database would share the same interpreter setting. such as > keytab, principal, common.max_count. And it just depends on the propertyKey > to decide to connect which database. I would say it is better to create one > interpreter setting for each database rather than mixing them together, > this would cause JdbcInterpreter very fragile, as changes for one database > may affect other databases. I am not sure whether this is because creating > new interpreter setting is not available when the jdbc interpreter is > implemented. if user create interpreter setting for each database, then he > doesn't need to specify `(mysql)` as point 1. > > Welcome any comments and thoughts on this. >
