Hi Samrat,

I'm still having doubts about the dependency on the JDBC connector. When a
user specifies 'read mode', it will use the JDBC connector under the hood.
Why not integrate Redshift then directly in the JDBC connector itself? It
removes the need for a dependency on the JDBC driver, especially keeping in
mind that this driver uses the old SourceFunction/SinkFunction interfaces
because it hasn't been migrated yet.

Best regards,

Martijn

On Mon, Sep 11, 2023 at 8:54 AM Samrat Deb <decordea...@gmail.com> wrote:

> Hi Leonard,
>
> > Do we have to rely on the latest version of JDBC Connector here?
>
> No, there's no need for us to depend on the latest version of the JDBC
> Connector. Redshift has its dedicated JDBC driver [1], which includes
> custom modifications tailored to Redshift's specific implementation needs.
> This driver is the most suitable choice for our purposes.
>
>
> > Could you collect the APIs that Redshift generally needs to use?
>
> I am actively working on it and making progress towards creating the POC.
>
> Bests,
> Samrat
>
> [1]
>
> https://docs.aws.amazon.com/redshift/latest/mgmt/jdbc20-download-driver.html
>
> On Mon, Sep 11, 2023 at 12:02 PM Samrat Deb <decordea...@gmail.com> wrote:
>
> > Hello Danny,
> >
> > I wanted to express my gratitude for your valuable feedback and
> insightful
> > suggestions.
> >
> > I will be revising the FLIP to incorporate all of your queries and review
> > suggestions. Additionally, I plan to provide a Proof of Concept (POC) for
> > the connector by the end of this week. This POC will address the points
> > you've raised and ensure that the FLIP aligns with your recommendations.
> >
> > Thank you once again for your input.
> >
> > Bests,
> > Samrat
> >
> > On Thu, Sep 7, 2023 at 10:21 PM Danny Cranmer <dannycran...@apache.org>
> > wrote:
> >
> >> Hello Leonard,
> >>
> >> > Do we have to rely on the latest version of JDBC Connector here? I
> >> understand that as long as the version of flink minor is the same as the
> >> JDBC Connector, Could you collect the APIs that Redshift generally needs
> >> to
> >> use?
> >>
> >> I agree we do not necessarily need to rely on the latest patch version,
> >> only the same minor. The main issue for me is the dependency introduces
> a
> >> blocker following a new Flink version. For example, when Flink 1.18.0 is
> >> released we cannot release the AWS connectors until the JDBC is
> complete.
> >> But I think this is a good tradeoff.
> >>
> >> > Splitting a separate redshift repository does not solve this coupling
> >> problem
> >>
> >> Arguably it solves the AWS<>JDBC coupling problem, but creates a new,
> more
> >> complex one!
> >>
> >> Thanks,
> >>
> >> On Thu, Sep 7, 2023 at 5:26 PM Leonard Xu <xbjt...@gmail.com> wrote:
> >>
> >> > Thanks Samrat and  Danny for driving this FLIP.
> >> >
> >> > >> an effective approach is to utilize the latest version of
> >> > flink-connector-jdbc
> >> > > as a Maven dependency
> >> > >
> >> > > When we have stable source/sink APIs and the connector versions are
> >> > > decoupled from Flink this makes sense. But right now this would mean
> >> that
> >> > > the JDBC connector will block the AWS connector for each new Flink
> >> > version
> >> > > support release (1.18, 1.19, 1.20, 2.0 etc). That being said, I
> cannot
> >> > > think of a cleaner alternative, without pulling the core JDBC bits
> out
> >> > into
> >> > > a dedicated project that is decoupled from and released
> independently
> >> of
> >> > > Flink. Splitting flink-connector-redshift into a dedicated repo
> would
> >> > > decouple AWS/JDBC, but obviously introduce a new connector that is
> >> > blocked
> >> > > by both AWS and JDBC.
> >> >
> >> > Do we have to rely on the latest version of JDBC Connector here? I
> >> > understand that as long as the version of flink minor is the same as
> the
> >> > JDBC Connector, Could you collect the APIs that Redshift generally
> >> needs to
> >> > use?
> >> >
> >> > Assuming that AWS Connector(Redshift) depends on JDBC Connector and
> >> wants
> >> > a higher version of JDBC Connector, I understand that the correct
> >> approach
> >> > is to promote the release of JDBC Connector and looks like we have no
> >> more
> >> > options.
> >> >
> >> > Splitting a separate redshift repository does not solve this coupling
> >> > problem, from a user perspective, redshift should also be in the AWS
> >> > Connector repo.
> >> >
> >> > Best,
> >> > Leonard
> >>
> >
>

Reply via email to