Hi Boto,
Thanks for driving this FLIP. +1 for it.
I would also ask to include a sample usage and changes for end-users in the
FLIP.
flink-connector-jdbc: The current module, which will be transformed to
> shade all other modules and maintain backward compatibility.
Also, in order to ensure the backwards compatibility, do you think at some
point we might need to decouple interface and implementations and put only
interfaces in flink-connector-jdbc module?
Regards,
Jeyhun
On Fri, May 3, 2024 at 2:56 PM João Boto <eskabe...@apache.org> wrote:
> Hi,
>
> > > You can now update the derby implementation and the core independently
> and decide at your own will when to include the new derby in the core?
> Not really, we are talking about creating modules in the same repository,
> not about externalizing the database modules. That is, whenever there is a
> release, both the core and the DBs will be released at the same time.
>
> > > For clarity of motivation, could you please add some concrete examples
> (just a couple) to the FLIP to clarify when this really comes in handy?
> Added.
>
> Best
>
> On 2024/04/26 07:59:30 lorenzo.affe...@ververica.com.INVALID wrote:
> > Hello Joao,
> > thank your for your proposal, modularity is always welcome :)
> >
> > > To maintain clarity and minimize conflicts, we're currently leaning
> towards maintaining the existing structure, where
> flink-connector-jdbc-${version}.jar remains shaded for simplicity,
> encompassing the core functionality and all database-related features
> within the same JAR.
> >
> > I do agree with this approach as the usecase of reading/writing to
> different DBs could be quite common.
> >
> > However, I am missing what would be the concrete advantage in this
> change for connector maintainability.
> > I make an example:
> > You can now update the derby implementation and the core independently
> and decide at your own will when to include the new derby in the core?
> >
> > For clarity of motivation, could you please add some concrete examples
> (just a couple) to the FLIP to clarify when this really comes in handy?
> >
> > Thank you!
> > On Apr 26, 2024 at 04:19 +0200, Muhammet Orazov
> <mor+fl...@morazow.com.invalid>, wrote:
> > > Hey João,
> > >
> > > Thanks for FLIP proposal!
> > >
> > > Since proposal is to introduce modules, would it make sense
> > > to have another module for APIs (flink-jdbc-connector-api)?
> > >
> > > For this I would suggest to move all public interfaces (e.g,
> > > JdbcRowConverter, JdbcConnectionProvider). And even convert
> > > some classes into interface with their default implementations,
> > > for example, JdbcSink, JdbcConnectionOptions.
> > >
> > > This way users would have clear interfaces to build their own
> > > JDBC based Flink connectors.
> > >
> > > Here I am not suggesting to introduce new interfaces, only
> > > suggest also to separate the API from the core implementation.
> > >
> > > What do you think?
> > >
> > > Best,
> > > Muhammet
> > >
> > >
> > > On 2024-04-25 08:54, Joao Boto wrote:
> > > > Hi all,
> > > >
> > > > I'd like to start a discussion on FLIP-449: Reorganization of
> > > > flink-connector-jdbc [1].
> > > > As Flink continues to evolve, we've noticed an increasing level of
> > > > complexity within the JDBC connector.
> > > > The proposed solution is to address this complexity by separating the
> > > > core
> > > > functionality from individual database components, thereby
> streamlining
> > > > the
> > > > structure into distinct modules.
> > > >
> > > > Looking forward to your feedback and suggestions, thanks.
> > > > Best regards,
> > > > Joao Boto
> > > >
> > > > [1]
> > > >
> https://cwiki.apache.org/confluence/display/FLINK/FLIP-449%3A+Reorganization+of+flink-connector-jdbc
> >
>
