napisał(a):
> >
> > > Hi Yuan, thanks for launching this discussion.
> > >
> > > I prefer option-3 as this is the easiest to understand for users.
> > >
> > >
> > > Best
> > > Yun Tang
> > >
> > > From: Rom
t; >
> > I prefer option-3 as this is the easiest to understand for users.
> >
> >
> > Best
> > Yun Tang
> >
> > From: Roman Khachatryan
> > Sent: Monday, May 31, 2021 16:53
> > To: dev
> > Subject: Re
Re: [DISCUSS][Statebackend][Runtime] Changelog Statebackend
> Configuration Proposal
>
> Hey Yuan, thanks for the proposal
>
> I think Option 3 is the simplest to use and exposes less details than any
> other.
> It's also consistent with the current way of configuring state
&
Hi Yuan, thanks for launching this discussion.
I prefer option-3 as this is the easiest to understand for users.
Best
Yun Tang
From: Roman Khachatryan
Sent: Monday, May 31, 2021 16:53
To: dev
Subject: Re: [DISCUSS][Statebackend][Runtime] Changelog Statebackend
Hey Yuan, thanks for the proposal
I think Option 3 is the simplest to use and exposes less details than any other.
It's also consistent with the current way of configuring state
backends, as long as we treat change logging as a common feature
applicable to any state backend, like e.g.
Hey all,
We would like to start a discussion on how to enable/config Changelog
Statebakcend.
As part of FLIP-158[1], Changelog state backend wraps on top of existing
state backend (HashMapStateBackend, EmbeddedRocksDBStateBackend and may
expect more) and delegates state changes to the underlying
