Not sure. One solution might be moving the PipelineOptionsReflectionSetter class to SQL package and make it package private. This will prevent the exposure but the downside would be I need to make PipelineOptionsFactory.parseObjects() public or duplicate its code. Do you think this approach might be better? I would also appreciate if you have another suggestion to solve this.
Best, Alireza On Tue, Jun 25, 2019 at 8:40 AM Lukasz Cwik <lc...@google.com> wrote: > That makes sense. I took a look at your PR, is there a way to do it > without exposing the reflection capabilities to pipeline authors? > > On Mon, Jun 24, 2019 at 2:20 PM Alireza Samadian <asamad...@google.com> > wrote: > >> Hi all, >> >> I am writing to ask if it is OK to slightly change the behaviour of SET >> command in JDBC connection of Beam SQL. Currently, if we try to use set >> command for an option that does not exist or setting an option to an >> illegal value, it does not show any error until we run a query. This means >> one can potentially set it incorrectly and then reset it correctly and run >> query without getting any error. However, I want to make some changes in >> JDBC Driver that causes this behavior to be changed. After this change, if >> someone tries to use set command for a wrong pipeline option (in JDBC >> path), it will immediately see an error message. >> >> The reason for this change is because I am working on the Jira issue >> https://issues.apache.org/jira/projects/BEAM/issues/BEAM-7590, and I am >> removing the Pipeline Option Map representation and keep the actual >> pipeline options instead. As a result, each time that the set command is >> called, it will try to change the pipeline options instance using >> reflection instead of changing a map, and later constructing pipeline >> options from it. >> >> The following is a link to the pull request: >> https://github.com/apache/beam/pull/8928 >> >> Best, >> Alireza Samadian >> >
