> In the case of a missed update, we'll have a new value and we can send a
tombstone to the view with the timestamp of the most recent update.
> then something has gone wrong and we should issue a tombstone using the
paxos repair timestamp as the tombstone timestamp.
The current MV implementation
You replied accurately to what i said, we're aligned. One point to
continue is below…
> And then, will the confidence of jdk12 in trunk be complete before its
> merge, and at what point can jdk11 safely be dropped ?
>
> The action of dropping jdk11 in trunk is just a one-liner in build.xml
> (a
That’s a good point, although as described I don’t think that could ever work
properly, even in normal operation. Either we’re misunderstanding something, or
this is a flaw in the current MV design.
Assuming changing the view indexed column results in a tombstone being applied
to the view row
>
> I respectfully mean that contributors, reviewers, and committers can't
> feasibly understand and enforce the ASF guidelines.
>
If this is true, then the ASF is in a lot of trouble and you should bring
it up with the ASF board.
How many people are aware that if you get code from OpenAI direct
> it might not always be smooth sailing – we might be losing some agility. But
> let's give it a go and find out.
Yeah, good point. When I bring it to VOTE I'll see if I can't massage the
wording a tiny bit around our intent to get to latest LTS support on trunk but
retain flexibility to wait i
> I’m not sure if this is the only edge case—there may be other issues as
well. I’m also unsure whether we should redesign the tombstone handling for
MVs, since that would involve changes to the storage engine. To minimize
impact there, the original proposal was to rebuild the affected ranges
usin
The current design leverages strict liveness to shadow the old view row.
When the view-indexed value changes from 'a' to 'b', no tombstone is
written; instead, the old row is marked as expired by updating its liveness
info with the timestamp of the change. If the column is later set back to
'a', th
> How did jdk12 suddenly appear ? How did that happen in trunk ?
> While 2.0 was trunk, it must have started off as jdk11 only. During trunk dev
> jdk12 was worked on, and the runtime aspect of jdk12 backported to 1.0.
I'm having a hard time tracking what you're saying here. =/
Another way of p
+1 that this is something that would be very valuable to our users.
As to where it lives, my gut reaction is to have the coordination, stop/start,
etc live inside the sidecar and lean on the DB for the durable distributed lock
to make the process atomic. Ultimately I'd like to see us move to the
Pushing a little for added clarity, see inline, while totally fine with
this approach.
Then we release the next C* version; for sake of illustration let's assume
> a new JDK LTS 12:
>
>- C* 2.0 / 12 / 12 / 12
>- C* 1.0 / 11 / 11+12 / 11
>
>
How did jdk12 suddenly appear ? How did that h
Hi,
I am not saying you said it, but I respectfully mean that contributors,
reviewers, and committers can't feasibly understand and enforce the ASF
guidelines. We would be another link in a chain of people abdicating
responsibility starting with LLM vendors serving up models that reproduce
cop
11 matches
Mail list logo
