Hi Mayank,

Thanks for the initiative! I think this functionality would be a really
great addition to Flink.

+1 for the proposal.

Thanks,
Yash

On Tue, May 6, 2025 at 9:36 AM Mayank Juneja <mayankjunej...@gmail.com>
wrote:

> Hi Ferenc,
>
> Thanks for your question! We agree that a CONNECTION could logically be a
> catalog-level resource, especially since it’s intended to be reused across
> multiple tables. However, we think there’s value in defining it at the
> database level to introduce a layer of isolation and scoping.
>
> This is particularly useful in shared or multi-tenant environments where
> different databases within the same catalog might need to connect to
> different external systems or use distinct credentials.
>
> That said, we’re open to revisiting this if there's strong consensus around
> catalog-level scoping. Appreciate the feedback!
>
> Regards,
> Mayank
>
> On Fri, May 2, 2025 at 12:12 AM Ferenc Csaky <ferenc.cs...@pm.me.invalid>
> wrote:
>
> > Hi Mayank,
> >
> > Thank you for starting the discussion! In general, I think such
> > functionality
> > would be a really great addition to Flink.
> >
> > Could you pls. elaborate a bit more one what is the reason of defining a
> > `connection` resource on the database level instead of the catalog level?
> > If I think about `JdbcCatalog`, or `HiveCatalog`, the catalog is in
> 1-to-1
> > mapping with an RDBMS, or a HiveMetastore, so my initial thinking is
> that a
> > `connection` seems more like a catalog level resource.
> >
> > WDYT?
> >
> > Thanks,
> > Ferenc
> >
> >
> >
> > On Tuesday, April 29th, 2025 at 17:08, Mayank Juneja <
> > mayankjunej...@gmail.com> wrote:
> >
> > >
> > >
> > > Hi all,
> > >
> > > I would like to open up for discussion a new FLIP-529 [1].
> > >
> > > Motivation:
> > > Currently, Flink SQL handles external connectivity by defining
> endpoints
> > > and credentials in table configuration. This approach prevents
> > reusability
> > > of these connections and makes table definition less secure by exposing
> > > sensitive information.
> > > We propose the introduction of a new "connection" resource in Flink.
> This
> > > will be a pluggable resource configured with a remote endpoint and
> > > associated access key. Once defined, connections can be reused across
> > table
> > > definitions, and eventually for model definition (as discussed in
> > FLIP-437)
> > > for inference, enabling seamless and secure integration with external
> > > systems.
> > > The connection resource will provide a new, optional way to manage
> > external
> > > connectivity in Flink. Existing methods for table definitions will
> remain
> > > unchanged.
> > >
> > > [1] https://cwiki.apache.org/confluence/x/cYroF
> > >
> > > Best Regards,
> > > Mayank Juneja
> >
>
>
> --
> *Mayank Juneja*
> Product Manager | Data Streaming and AI
>

Reply via email to