Pass runtime configs & variables to BeamSqlSeekableTable

[gabrywu]

fixes #28145

[github-actions]

Checks are failing. Will not request review until checks are succeeding. If you'd like to override that behavior, comment assign set of reviewers

[liferoad]

R: @Abacn

[liferoad]

R: @bvolpato

[liferoad]

R: @kennknowles

[github-actions]

Stopping reviewer notifications for this pull request: review requested by someone other than the bot, ceding control

[bvolpato]

Thanks! No major concerns from me -- just one note is that relying on PipelineOptions will allow configuring behavior for the entire job.

Sometimes it's better to use a specific configuration class / instance, so you could likely have multiple JOINs in the same job and each handle different things.

[Abacn]

LGTM. It's totally reasonable to add the method as they corresponding the dofn lifecycle methods. Probably we should add them at the beginning.

• One thing to note when implementing youe own BeamSqlSeekableTable. startBundle can be called many times, so if initializing a connection in it, it's good to use a connection pool otherwise there could be too much connection - a common issue seen in Beam IO implementation

also, its nice to have a test checking dofn lifecycle is effective with BeamSqlSeekableTable methods.

[gabrywu]

LGTM. It's totally reasonable to add the method as they corresponding the dofn lifecycle methods. Probably we should add them at the beginning.

• One thing to note when implementing youe own BeamSqlSeekableTable. startBundle can be called many times, so if initializing a connection in it, it's good to use a connection pool otherwise there could be too much connection - a common issue seen in Beam IO implementation

also, its nice to have a test checking dofn lifecycle is effective with BeamSqlSeekableTable methods.

thanks very much. I will add an initialized flag to startBundle in our own BeamSqlSeekableTable to avoid too much connection.