Sure thing.
https://debezium.io is an open-source project largely developed by Red Hat that
standardizes change data capture across a variety of data sources. It ships
with connectors for Oracle, SQL Server, MySQL, PostgreSQL, and MongoDB, and
typically records changes into topics in Apache Kaf
I support removing obsolete fields from responses.
I also support tracking API changes.
Donat
On Fri, Apr 2, 2021 at 10:23 PM Robert Newson wrote:
>
> +1 to removing “node” on main (but not 3.x branch).
>
> B.
>
> > On 2 Apr 2021, at 21:11, Ilya Khlopotov wrote:
> >
> > Hi,
> >
> > In FDB worl
Thank you for sharing the idea, Adam. I like it!
Can you please share some details?
Donat
On Wed, Mar 31, 2021 at 2:14 AM Adam Kocoloski wrote:
>
> I would bias towards ecosystem integrations, e.g. a metrics exporter for
> Prometheus (I think one is in the works), or a Debezium connector for
Nice list of questions. Couple more from me:
# global vs per endpoint?
If we decide for API per endpoint we could different mechanisms to get list of
supported versions:
- new /_api endpoint which would return list of versions for each endpoint
```
{
"/{db}/{docid}": ["4", "55", "95
+1 to removing “node” on main (but not 3.x branch).
B.
> On 2 Apr 2021, at 21:11, Ilya Khlopotov wrote:
>
> Hi,
>
> In FDB world there wouldn't be erlang mesh as far as I can tell. In this
> situation the `node` field in the response from `/_scheduler/jobs` and
> `/_scheduler/docs` doesn't
Hi,
In FDB world there wouldn't be erlang mesh as far as I can tell. In this
situation the `node` field in the response from `/_scheduler/jobs` and
`/_scheduler/docs` doesn't make sense.
We could either remove the field or set it to `None`. I propose complete
removal.
I also propose to est
Hi Glynn, my thoughts in-line:
> On Apr 2, 2021, at 1:40 AM, Glynn Bird wrote:
>
> Is there a possibility that a future replicator, instead of consuming the
> "firehose" changes feed, could instead be split into
> 1-worker-per-changes-feed-shard as a neat way of parallelizing data
> transfer?
I
