As an FYI.
It's a misrepresentation to suggest that ES/CQRS requires each actor/aggregate
root history to be materialised as a physically distinct stream. There may be
specific implementations that require this, and I know there are others that do
not.So regarding those references given, it's i
The best practices page says in "write ordering" , use the core api if you need
strict write order in the log.
Can I have a little more clarity what this means.
I assumed that whether I use the fat or thin client that the writes I make
would be ordered in the log in bk.
I assume I am misunderstan
Yes please
Original message From: Xi Liu Date:
14/10/2016 10:18 (GMT+00:00) To: dev@distributedlog.incubator.apache.org
Subject: Re: BookKeeper Meetup on Nov 15th
Will this event be streaming?
- Xi
On Fri, Oct 14, 2016 at 12:57 AM, Sijie Guo wrote:
> FYI. If you are inter
.
Can you tolerate this for another few weeks?
Thanks.
On Tue, Sep 20, 2016 at 10:25 AM, john.lonergan
wrote:
> for the moment wound or be possible to build the BK fork as an artefact in
> the twitter group in central so we don't need to build it ourselves.
>
>
ep 20, 2016 at 10:37 AM, john.lonergan
wrote:
> Docs say the txn Id is an application supplied sequence number. It is
> required to be non-decreasing. Users usually use either timestamp or offset.
> What are the consequences of publishing two consecutive messages with the
> same txn ids.
>
Docs say the txn Id is an application supplied sequence number. It is required
to be non-decreasing. Users usually use either timestamp or offset.
What are the consequences of publishing two consecutive messages with the same
txn ids.
for the moment wound or be possible to build the BK fork as an artefact in the
twitter group in central so we don't need to build it ourselves.
Please
