If there is no more questions or concerns, I will start the voting thread
tomorrow
On 2022/06/27 13:09:51 Roc Marshal wrote:
> Hi, all,
>
>
>
>
> I would like to open a discussion on porting JDBC Source to new Source API
> (FLIP-27[1]).
>
> Martijn Visser, Jing Ge and I had a preliminary d
I have update the FLIP with the 2 options that we have discussed..
Option 1: Expose ExecutionConfig directly on InitContext
this have a minimal impact as we only have to expose the new methods
Option 2: Expose ReadableExecutionConfig on InitContext
with this option we have more impact as we need
a new method
> `TypeInformation#createSerializer(ReadableExecutionConfig)`. The new
> method may require every `TypeInformation` to implement it, including
> Flink built-in ones and custom ones, otherwise exceptions will happen.
> That goal, however, is pretty hard to achieve.
>
&g
utionConfig`.
> > > >
> > > > We can rework all the setters of `ExecutionConfig` to internally
> > invoke a
> > > > `setConfiguration(...)` method. Then the `ReadableExecutionConfig` can
> > > > just override that method. But pay attention to a few excepti
Updated the FLIP to use this option.
zer:
>
> (1) TypeSerializer createInputSerializer();
> (2) TypeSerializer createSerializer(TypeInformation inType);
>
> Is the method (2) still needed now?
>
> Best,
> Lijie
>
> João Boto 于2023年5月19日周五 16:53写道：
>
> > Updated the FLIP to use this option.
> >
>
If there is no more questions, I will start the voting thread tomorrow
On 2023/01/13 14:15:04 Joao Boto wrote:
> Hi flink devs,
>
> I'd like to start a discussion thread for FLIP-287[1].
> This comes from an offline discussion with @Lijie Wang, from FLIP-239[2]
> specially for the sink[3].
>
> B
Hi,
On source we could improve the JdbcParameterValuesProvider.. to be defined as a
query(s) or something more dynamic.
The most time if your job is dynamic or have some condition to be met (based on
data on table) you have to create a connection an get that info from database
If we are going t
Hi Gunnar,
Thanks for your time and response...
I think the problem you want to solve is the exposure of the ExecutionConfig
(that can be mutated) no?
The configuration is not mutated, we only need to know if objectReuse is
enable.
This is already expose on RuntimeContext we think to keep it s
Hi all,
After an offline talk with Gunnar I review all connectors on branch
release_1.16 (still has virtually all connectors) we can see some of them using
ExecutionConfig..
The basic use is for creating serializers:
TypeInformation.createSerializer(ExecutionConfig config), and since it is a
F
ain/java/org/apache/flink/streaming/runtime/operators/sink/SinkWriterOperator.java#L279
>
> On Fri, Jan 13, 2023 at 6:19 PM João Boto wrote:
>
> > Hi Gunnar,
> > Thanks for your time and response...
> >
> > I think the problem you want to solve is the exposure of the
Hi all,
As establish a read-only contract seems to be consensual approach, talking to
Lijie we saw two ways for doing this..
Option 1: UnmodifiableExecutionConfig that extends ExecutionConfig (just like
the UnmodifiableConfiguration)
Pros:
- we have all the get methods
- don't need to change T
Hi Pan,
Users who wish to utilize only one database and prefer not to use
flink-connector-jdbc-${version}.jar + ${database-connector-driver}.jar should
opt for option 1: flink-connector-jdbc-core-${version}.jar +
flink-connector-jdbc-mysql-${version}.jar + ${database-connector-driver}.jar.
We
Hi Muhammet,
While I generally agree, given our current usage, I'm struggling to discern any
clear advantage. We already have abstract implementations that cover all
necessary interfaces and offer essential functionality, complemented by a
robust set of reusable tests to streamline implementati
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 ther
ce would have been helpful.
>
> But I agree maybe the interface module separation is not required at the
> moment.
>
> Thanks for your efforts!
>
> Best,
> Muhammet
>
>
> On 2024-05-03 12:25, João Boto wrote:
> > Hi Muhammet,
> >
> > While I gene
terfaces in flink-connector-jdbc module?
>
> Regards,
> Jeyhun
>
> On Fri, May 3, 2024 at 2:56 PM João Boto wrote:
>
> > Hi,
> >
> > > > You can now update the derby implementation and the core independently
> > and decide at your own will when
Hmm sorry, I will try to search consensus..
I read 3 Votes but miss the binding part..
On 2024/05/16 01:36:46 Rui Fan wrote:
> Thanks Joao Boto for driving the FLIP. We need 3 +1(binding)
> votes according to Flink Bylaws[1] before the community accepts it.
>
> You can search "Consensus" and
I will send this with better format..
Sorry for that
On 2024/07/10 13:46:43 Joao Boto wrote:
> Hi,
>
> During the refactor related to FLIP-449[1], we start seeing this error on
> CI like:
>
> > - "You are running out of disk space. The runner will stop working when
> > the machine runs out of d
ction.yml#L54-L69
>
> On Wed, Jul 10, 2024 at 3:53 PM João Boto wrote:
>
> > I will send this with better format..
> > Sorry for that
> >
> > On 2024/07/10 13:46:43 Joao Boto wrote:
> > > Hi,
> > >
> > > During the refactor related to FLIP-
We could merge the two modules into one?
sequence-files its another way of compressing files..
On 2020/03/05 13:02:46, Sivaprasanna wrote:
> Hi Stephen,
>
> I guess it is a valid point to have something like 'flink-hadoop-utils'.
> Maybe a [DISCUSS] thread can be started to understand what the
21 matches
Mail list logo
