+1
—
AY
On 13 February 2018 at 03:41:09, Michael Shuler (mich...@pbandjelly.org) wrote:
I propose the following artifacts for release as 3.11.2.
sha1: 8a5e88f635fdb984505a99a553b5799cedccd06d
Git:
+1
—
AY
On 12 February 2018 at 20:30:58, Michael Shuler (mich...@pbandjelly.org) wrote:
I propose the following artifacts for release as 2.1.20.
sha1: b2949439ec62077128103540e42570238520f4ee
Git:
+1
—
AY
On 12 February 2018 at 20:31:23, Michael Shuler (mich...@pbandjelly.org) wrote:
I propose the following artifacts for release as 3.0.16.
sha1: 91e83c72de109521074b14a8eeae1309c3b1f215
Git:
+1
—
AY
On 12 February 2018 at 20:31:06, Michael Shuler (mich...@pbandjelly.org) wrote:
I propose the following artifacts for release as 2.2.12.
sha1: 1602e606348959aead18531cb8027afb15f276e7
Git:
There isn’t, or at least not that I know of.
Some time this year most likely. I don’t think anybody is in a rush for 4.0,
either.
—
AY
On 23 January 2018 at 15:40:36, Jakub Janco (jja...@redhat.com) wrote:
Hello,
is here any update? I can't find any new information.
Thanks.
--
Best
ows" or something similar would make
more sense then?
Le ven. 5 janv. 2018 à 20:24, Aleksey Yeshchenko <alek...@apple.com> a
écrit :
> Counting the number of range tombstones - sure, that is reasonable.
>
> Counting cells/rows shadowed by range tombstones toward the
redRowIterator interface to include the tombstones/rows/cells stats
> as this is what is returned from the lower levels of the read path.
> Is there any easier way to achieve this that you can think of, as that
> interface is used in many parts of the code ?
>
> On Wed, Dec 2
As Jeff says, the number of actual tombstones is no less relevant than the
number of
cells and rows shadowed by them. And the way row and cell tombstones affect a
read
query can be very different from the way a big range tombstone might: you
potentially
have to retain every (regular) tombstone
Strongly disagree with MV’s being isolated part.
You can feel the touch of the MVs in the read path, write path, metadata
handling, whether you use them or not. And comparing any of those before/after
MVs were introduced makes me sad every time I face any of it. It made our
codebase
Yep. Almost!
Changing the default in a minor version might break some scripts/tooling that
manipulate schema and potentially create new MVs (as dangerous as it currently
is - manipulating schema in that way), and that would still not be very nice.
Introducing a flag and leaving it at false in
Indeed. Paulo and Zhao did a lot of good work to make the situation less bad.
You did some as well. Even I retouched small parts of it - metadata related.
I’m sorry if I came off as disrespectful - I didn’t mean to. I’ve seen and I
appreciate every commit that went into it.
It is however my
gt;>
> >> Thanks,
> >> Thomas
> >>
> >> -Original Message-
> >> From: Jon Haddad [mailto:jonathan.had...@gmail.com] On Behalf Of Jon
> >> Haddad
> >> Sent: Montag, 02. Oktober 2017 22:09
> >> To: d
There are a couple compromise options here:
a) Introduce the flag (enalbe_experimental_features, or maybe one per
experimental feature), set it to ‘false’ in the yaml, but have the default be
‘true’. So that if you are upgrading from a previous minor to the next without
updating the yaml, you
Yep. And that would be nice to have in addition to the opt-in flag in the yaml
for the operators that’s stricter than a warning.
—
AY
On 2 October 2017 at 22:21:33, Jeremiah D Jordan (jerem...@datastax.com) wrote:
We are not saying to just put something in logs, we are talking about the warn
ture I
> think
> > >> that is pretty visible during development?
> > >>
> > >> I guess I can see just blocking new ones without a flag set, but we
> need
> > >> to be careful here. We need to make sure we don’t cause a problem for
> > >> someone tha
Thomas,
I would maybe agree with waiting for a while because of it, if we had a proper
fix at least under review - or in progress by someone.
But this is not a regression, and there’s been a lot of fixes accumulated and
not released yet. Arguable worse to hold them back :\
—
AY
On 2 October
+1
—
AY
On 2 October 2017 at 18:58:57, Michael Shuler (mich...@pbandjelly.org) wrote:
I propose the following artifacts for release as 3.11.1.
sha1: 983c72a84ab6628e09a78ead9e20a0c323a005af
Git:
+1
—
AY
On 2 October 2017 at 18:18:26, Michael Shuler (mich...@pbandjelly.org) wrote:
I propose the following artifacts for release as 3.0.15.
sha1: b32a9e6452c78e6ad08e371314bf1ab7492d0773
Git:
The idea is to check the flag in CreateViewStatement, so creation of new MVs
doesn’t succeed without that flag flipped.
Obviously, just disabling existing MVs working in a minor would be silly.
As for the warning - yes, that should also be emitted. Unconditionally.
—
AY
On 2 October 2017 at
> I appreciate the update!
>
> --
> Michael
>
> On 09/28/2017 10:50 AM, Aleksey Yeshchenko wrote:
> > FWIW, none of the remaining issues are strictly speaking regressions
> from previous versions.
> >
> > So if we felt strongly about st
+1
—
AY
On 28 September 2017 at 19:12:19, Michael Shuler (mich...@pbandjelly.org) wrote:
I propose the following artifacts for release as 2.1.19.
sha1: 428eaa3e37cab7227c81fdf124d29dfc1db4257c
Git:
4.0 should also fail startup (very early) if it still sees any non-migrated
tables, probably.
—
AY
On 19 September 2017 at 18:35:11, J. D. Jordan (jeremiah.jor...@gmail.com)
wrote:
Thanks for the clarification. +1 for adding a "DROP COMPACT STORAGE" option in
3.x and then not allowing it to
It doesn’t work between any two majors (1.2 and 2.0, 2.0 and 2.1, 2.1 and 3.0).
The reason is that hint delivery doesn’t proceed between two nodes unless they
have the same schema version,
and in every recent major release we made changes that made schema calculation
differ even without any DDL
101 - 123 of 123 matches
Mail list logo
