You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Jon Haddad <jo...@jonhaddad.com> on 2020/04/01 18:27:13 UTC
server side describe
Hey folks,
I was looking through our open JIRAs and realized we hadn't merged in
server side describe calls yet. The ticket died off a ways ago, and I
pinged Chris about it yesterday. He's got a lot of his plate and won't be
able to work on it anytime soon. I still think we should include this in
4.0.
From a technical standpoint, It doesn't say much on the ticket after Robert
tossed an alternative patch out there. I don't mind reviewing and merging
either of them, it sounded like both are pretty close to done and I think
from the perspective of updating drivers for 4.0 this will save quite a bit
of time since driver maintainers won't have to add new CQL generation for
the various new options that have recently appeared.
Questions:
* Does anyone have an objection to getting this into 4.0? The patches
aren't too huge, I think they're low risk, and also fairly high reward.
* I don't have an opinion (yet) on Robert's patch vs Chris's, with regard
to which is preferable.
* Since soon after Robert put up his PR he hasn't been around, at least as
far as I've seen. How have we dealt with abandoned patches before? If
we're going to add this in the patch will need some cleanup. Is it
reasonable to continue someone else's work when they've disappeared?
Jon
Re: server side describe
Posted by Joshua McKenzie <jm...@apache.org>.
>
> Someone once said:
In my opinion, sniping like this doesn't help us move the conversation
forward. Please reach out to other contributors who's behavior you have
concerns with separately.
On Fri, Apr 3, 2020 at 12:23 PM Joshua McKenzie <jm...@apache.org>
wrote:
> This isn't a hill to die on or something to binding -1 for me
> personally. In a vacuum this merge is totally fine. The problem for me
> comes in if a merge like this is one of 10, or 50, or 100 things that
> are innocuous in isolation. IMO as long as we make sure this is the
> only cut we do to ourselves we won't face death by a thousand cuts on
> 4.0.
>
> In general I'm concerned about our rigor and discipline on restricting
> scope to get 4.0 out the door, but that's in no way unique to us as a
> project or 4.0 as a release; this has happened with every large
> software release I've ever worked on and always requires significant
> discomfort to lock down. It's unfortunate that the situation with this
> ticket stumbled across that sore point for me (and likely many of us),
> but I think we should keep that to the other thread about scope.
>
> On Fri, Apr 3, 2020 at 11:34 AM Jeff Jirsa <jj...@gmail.com> wrote:
> >
> > Someone once said:
> >
> > "I heard the expression recently that “there are ten ways to do this, and
> > eight of them will work.” I think that applies to most of the code we
> > write. We don't need to spend a lot of time discussing which of the
> eight
> > is best; let’s trust the judgement of the original author and move
> > forward. "
> >
> > Had we applied that principle to this JIRA the first time the patch was
> > available in OCTOBER 2018, we wouldn't be having a conversation about
> > whether or not it violates a freeze.
> >
> >
> > On Wed, Apr 1, 2020 at 11:37 AM Jonathan Ellis <jb...@gmail.com>
> wrote:
> >
> > > I think we should get serious about the so-called freeze.
> > >
> > > On Wed, Apr 1, 2020 at 1:27 PM Jon Haddad <jo...@jonhaddad.com> wrote:
> > >
> > > > Hey folks,
> > > >
> > > > I was looking through our open JIRAs and realized we hadn't merged in
> > > > server side describe calls yet. The ticket died off a ways ago, and
> I
> > > > pinged Chris about it yesterday. He's got a lot of his plate and
> won't
> > > be
> > > > able to work on it anytime soon. I still think we should include
> this in
> > > > 4.0.
> > > >
> > > > From a technical standpoint, It doesn't say much on the ticket after
> > > Robert
> > > > tossed an alternative patch out there. I don't mind reviewing and
> > > merging
> > > > either of them, it sounded like both are pretty close to done and I
> think
> > > > from the perspective of updating drivers for 4.0 this will save
> quite a
> > > bit
> > > > of time since driver maintainers won't have to add new CQL
> generation for
> > > > the various new options that have recently appeared.
> > > >
> > > > Questions:
> > > >
> > > > * Does anyone have an objection to getting this into 4.0? The patches
> > > > aren't too huge, I think they're low risk, and also fairly high
> reward.
> > > > * I don't have an opinion (yet) on Robert's patch vs Chris's, with
> regard
> > > > to which is preferable.
> > > > * Since soon after Robert put up his PR he hasn't been around, at
> least
> > > as
> > > > far as I've seen. How have we dealt with abandoned patches before?
> If
> > > > we're going to add this in the patch will need some cleanup. Is it
> > > > reasonable to continue someone else's work when they've disappeared?
> > > >
> > > > Jon
> > > >
> > >
> > >
> > > --
> > > Jonathan Ellis
> > > co-founder, http://www.datastax.com
> > > @spyced
> > >
>
Re: server side describe
Posted by Joshua McKenzie <jm...@apache.org>.
This isn't a hill to die on or something to binding -1 for me
personally. In a vacuum this merge is totally fine. The problem for me
comes in if a merge like this is one of 10, or 50, or 100 things that
are innocuous in isolation. IMO as long as we make sure this is the
only cut we do to ourselves we won't face death by a thousand cuts on
4.0.
In general I'm concerned about our rigor and discipline on restricting
scope to get 4.0 out the door, but that's in no way unique to us as a
project or 4.0 as a release; this has happened with every large
software release I've ever worked on and always requires significant
discomfort to lock down. It's unfortunate that the situation with this
ticket stumbled across that sore point for me (and likely many of us),
but I think we should keep that to the other thread about scope.
On Fri, Apr 3, 2020 at 11:34 AM Jeff Jirsa <jj...@gmail.com> wrote:
>
> Someone once said:
>
> "I heard the expression recently that “there are ten ways to do this, and
> eight of them will work.” I think that applies to most of the code we
> write. We don't need to spend a lot of time discussing which of the eight
> is best; let’s trust the judgement of the original author and move
> forward. "
>
> Had we applied that principle to this JIRA the first time the patch was
> available in OCTOBER 2018, we wouldn't be having a conversation about
> whether or not it violates a freeze.
>
>
> On Wed, Apr 1, 2020 at 11:37 AM Jonathan Ellis <jb...@gmail.com> wrote:
>
> > I think we should get serious about the so-called freeze.
> >
> > On Wed, Apr 1, 2020 at 1:27 PM Jon Haddad <jo...@jonhaddad.com> wrote:
> >
> > > Hey folks,
> > >
> > > I was looking through our open JIRAs and realized we hadn't merged in
> > > server side describe calls yet. The ticket died off a ways ago, and I
> > > pinged Chris about it yesterday. He's got a lot of his plate and won't
> > be
> > > able to work on it anytime soon. I still think we should include this in
> > > 4.0.
> > >
> > > From a technical standpoint, It doesn't say much on the ticket after
> > Robert
> > > tossed an alternative patch out there. I don't mind reviewing and
> > merging
> > > either of them, it sounded like both are pretty close to done and I think
> > > from the perspective of updating drivers for 4.0 this will save quite a
> > bit
> > > of time since driver maintainers won't have to add new CQL generation for
> > > the various new options that have recently appeared.
> > >
> > > Questions:
> > >
> > > * Does anyone have an objection to getting this into 4.0? The patches
> > > aren't too huge, I think they're low risk, and also fairly high reward.
> > > * I don't have an opinion (yet) on Robert's patch vs Chris's, with regard
> > > to which is preferable.
> > > * Since soon after Robert put up his PR he hasn't been around, at least
> > as
> > > far as I've seen. How have we dealt with abandoned patches before? If
> > > we're going to add this in the patch will need some cleanup. Is it
> > > reasonable to continue someone else's work when they've disappeared?
> > >
> > > Jon
> > >
> >
> >
> > --
> > Jonathan Ellis
> > co-founder, http://www.datastax.com
> > @spyced
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: server side describe
Posted by Jeff Jirsa <jj...@gmail.com>.
Someone once said:
"I heard the expression recently that “there are ten ways to do this, and
eight of them will work.” I think that applies to most of the code we
write. We don't need to spend a lot of time discussing which of the eight
is best; let’s trust the judgement of the original author and move
forward. "
Had we applied that principle to this JIRA the first time the patch was
available in OCTOBER 2018, we wouldn't be having a conversation about
whether or not it violates a freeze.
On Wed, Apr 1, 2020 at 11:37 AM Jonathan Ellis <jb...@gmail.com> wrote:
> I think we should get serious about the so-called freeze.
>
> On Wed, Apr 1, 2020 at 1:27 PM Jon Haddad <jo...@jonhaddad.com> wrote:
>
> > Hey folks,
> >
> > I was looking through our open JIRAs and realized we hadn't merged in
> > server side describe calls yet. The ticket died off a ways ago, and I
> > pinged Chris about it yesterday. He's got a lot of his plate and won't
> be
> > able to work on it anytime soon. I still think we should include this in
> > 4.0.
> >
> > From a technical standpoint, It doesn't say much on the ticket after
> Robert
> > tossed an alternative patch out there. I don't mind reviewing and
> merging
> > either of them, it sounded like both are pretty close to done and I think
> > from the perspective of updating drivers for 4.0 this will save quite a
> bit
> > of time since driver maintainers won't have to add new CQL generation for
> > the various new options that have recently appeared.
> >
> > Questions:
> >
> > * Does anyone have an objection to getting this into 4.0? The patches
> > aren't too huge, I think they're low risk, and also fairly high reward.
> > * I don't have an opinion (yet) on Robert's patch vs Chris's, with regard
> > to which is preferable.
> > * Since soon after Robert put up his PR he hasn't been around, at least
> as
> > far as I've seen. How have we dealt with abandoned patches before? If
> > we're going to add this in the patch will need some cleanup. Is it
> > reasonable to continue someone else's work when they've disappeared?
> >
> > Jon
> >
>
>
> --
> Jonathan Ellis
> co-founder, http://www.datastax.com
> @spyced
>
Re: server side describe
Posted by Jonathan Ellis <jb...@gmail.com>.
I think we should get serious about the so-called freeze.
On Wed, Apr 1, 2020 at 1:27 PM Jon Haddad <jo...@jonhaddad.com> wrote:
> Hey folks,
>
> I was looking through our open JIRAs and realized we hadn't merged in
> server side describe calls yet. The ticket died off a ways ago, and I
> pinged Chris about it yesterday. He's got a lot of his plate and won't be
> able to work on it anytime soon. I still think we should include this in
> 4.0.
>
> From a technical standpoint, It doesn't say much on the ticket after Robert
> tossed an alternative patch out there. I don't mind reviewing and merging
> either of them, it sounded like both are pretty close to done and I think
> from the perspective of updating drivers for 4.0 this will save quite a bit
> of time since driver maintainers won't have to add new CQL generation for
> the various new options that have recently appeared.
>
> Questions:
>
> * Does anyone have an objection to getting this into 4.0? The patches
> aren't too huge, I think they're low risk, and also fairly high reward.
> * I don't have an opinion (yet) on Robert's patch vs Chris's, with regard
> to which is preferable.
> * Since soon after Robert put up his PR he hasn't been around, at least as
> far as I've seen. How have we dealt with abandoned patches before? If
> we're going to add this in the patch will need some cleanup. Is it
> reasonable to continue someone else's work when they've disappeared?
>
> Jon
>
--
Jonathan Ellis
co-founder, http://www.datastax.com
@spyced
Re: server side describe
Posted by Benjamin Lerer <be...@datastax.com>.
It seems to me that we need to get better at making decisions for things
like that.
If we keep on arguing for small things, it will simply be time consuming
and painfull for everybody.
In this case, the situation seems simple.
Part of the group do not agree with the proposal. We just have to accept it
and move on.
On Fri, Apr 3, 2020 at 2:48 AM Joshua McKenzie <jm...@apache.org> wrote:
> One thing probably worth thinking about: we're a mostly irascible lot to
> begin with and there's a global pandemic and Human Race Lockdown. I don't
> know about the rest of you but I'm starting from a pretty not-chill place
> these days; trying to be mindful of that.
>
> So for this: if we require a protocol change there's a clear forcing
> function to get it into 4.0 since a) it's minor and b) the time horizon for
> the next major is very uncertain.
>
> If we go a route that doesn't require a protocol change it can just go into
> the next patch release after 4.0 right? Is there an urgency to get it into
> 4.0.0 I'm missing in this scenario?
>
>
> On Thu, Apr 2, 2020 at 5:25 PM sankalp kohli <ko...@gmail.com>
> wrote:
>
> > Whether a feature is fully done and whether it validates or invalidate
> > testing is not the point here. The point is that it is a feature and
> > violates feature freeze. If someone brings in a feature which is almost
> > done and does not invalidate testing then will we merge all of them to
> 4.0?
> > Lot of features can be merged then based on this justification!!
> >
> >
> > Considering this is a small feature, I wont -1 on it. I will disagree
> and
> > commit.
> >
> >
> >
> > On Thu, Apr 2, 2020 at 1:04 PM Jon Haddad <jo...@jonhaddad.com> wrote:
> >
> > > Chris's original patch used a virtual table which didn't even require a
> > > protocol change. To me, the difference between having a CQL describe
> vs
> > a
> > > virtual table is unimportant, since it's only drivers that need to care
> > > about it. I'm completely fine with the simpler implementation of a
> > virtual
> > > table.
> > >
> > > Quite a bit of Chris's patch also fixes our broken server side CQL
> > > generation, something that affects correctness in our snapshots. So
> > either
> > > way most of the code needs to go in before we release 4.0. Adding a
> > single
> > > file that creates a new virtual table is so trivial I'm having a hard
> > time
> > > understanding the opposition.
> > >
> > > On Thu, Apr 2, 2020 at 12:56 PM Nate McCall <zz...@gmail.com>
> wrote:
> > >
> > > > So summarizing the salient points here:
> > > > - client authors have worked around this mostly, but this would avoid
> > > some
> > > > duplication of effort for new features
> > > > - this issues was tagged last year as being pertinent to 4.0 in
> several
> > > > threads about what was in scope
> > > > - there is some development efforts required to review/merge/update
> > these
> > > > patches and we are trying to release
> > > > - the change is unintrusive
> > > > - this is a change to the protocol
> > > >
> > > > Not having this doesnt effect me for $dayJob, but I want to reiterate
> > > that
> > > > it's a silly thing to leave to clients. Given we've previously scoped
> > it
> > > to
> > > > 4.0, im still +1 on adding it.
> > > >
> > > > It's ok to have differing opinions. I'd like to see us disagree and
> > > commit
> > > > to a course of action either way as opposed to just letting it sit
> more
> > > > because we can't sort it out.
> > > >
> > >
> >
>
Re: server side describe
Posted by Joshua McKenzie <jm...@apache.org>.
One thing probably worth thinking about: we're a mostly irascible lot to
begin with and there's a global pandemic and Human Race Lockdown. I don't
know about the rest of you but I'm starting from a pretty not-chill place
these days; trying to be mindful of that.
So for this: if we require a protocol change there's a clear forcing
function to get it into 4.0 since a) it's minor and b) the time horizon for
the next major is very uncertain.
If we go a route that doesn't require a protocol change it can just go into
the next patch release after 4.0 right? Is there an urgency to get it into
4.0.0 I'm missing in this scenario?
On Thu, Apr 2, 2020 at 5:25 PM sankalp kohli <ko...@gmail.com> wrote:
> Whether a feature is fully done and whether it validates or invalidate
> testing is not the point here. The point is that it is a feature and
> violates feature freeze. If someone brings in a feature which is almost
> done and does not invalidate testing then will we merge all of them to 4.0?
> Lot of features can be merged then based on this justification!!
>
>
> Considering this is a small feature, I wont -1 on it. I will disagree and
> commit.
>
>
>
> On Thu, Apr 2, 2020 at 1:04 PM Jon Haddad <jo...@jonhaddad.com> wrote:
>
> > Chris's original patch used a virtual table which didn't even require a
> > protocol change. To me, the difference between having a CQL describe vs
> a
> > virtual table is unimportant, since it's only drivers that need to care
> > about it. I'm completely fine with the simpler implementation of a
> virtual
> > table.
> >
> > Quite a bit of Chris's patch also fixes our broken server side CQL
> > generation, something that affects correctness in our snapshots. So
> either
> > way most of the code needs to go in before we release 4.0. Adding a
> single
> > file that creates a new virtual table is so trivial I'm having a hard
> time
> > understanding the opposition.
> >
> > On Thu, Apr 2, 2020 at 12:56 PM Nate McCall <zz...@gmail.com> wrote:
> >
> > > So summarizing the salient points here:
> > > - client authors have worked around this mostly, but this would avoid
> > some
> > > duplication of effort for new features
> > > - this issues was tagged last year as being pertinent to 4.0 in several
> > > threads about what was in scope
> > > - there is some development efforts required to review/merge/update
> these
> > > patches and we are trying to release
> > > - the change is unintrusive
> > > - this is a change to the protocol
> > >
> > > Not having this doesnt effect me for $dayJob, but I want to reiterate
> > that
> > > it's a silly thing to leave to clients. Given we've previously scoped
> it
> > to
> > > 4.0, im still +1 on adding it.
> > >
> > > It's ok to have differing opinions. I'd like to see us disagree and
> > commit
> > > to a course of action either way as opposed to just letting it sit more
> > > because we can't sort it out.
> > >
> >
>
Re: server side describe
Posted by sankalp kohli <ko...@gmail.com>.
Whether a feature is fully done and whether it validates or invalidate
testing is not the point here. The point is that it is a feature and
violates feature freeze. If someone brings in a feature which is almost
done and does not invalidate testing then will we merge all of them to 4.0?
Lot of features can be merged then based on this justification!!
Considering this is a small feature, I wont -1 on it. I will disagree and
commit.
On Thu, Apr 2, 2020 at 1:04 PM Jon Haddad <jo...@jonhaddad.com> wrote:
> Chris's original patch used a virtual table which didn't even require a
> protocol change. To me, the difference between having a CQL describe vs a
> virtual table is unimportant, since it's only drivers that need to care
> about it. I'm completely fine with the simpler implementation of a virtual
> table.
>
> Quite a bit of Chris's patch also fixes our broken server side CQL
> generation, something that affects correctness in our snapshots. So either
> way most of the code needs to go in before we release 4.0. Adding a single
> file that creates a new virtual table is so trivial I'm having a hard time
> understanding the opposition.
>
> On Thu, Apr 2, 2020 at 12:56 PM Nate McCall <zz...@gmail.com> wrote:
>
> > So summarizing the salient points here:
> > - client authors have worked around this mostly, but this would avoid
> some
> > duplication of effort for new features
> > - this issues was tagged last year as being pertinent to 4.0 in several
> > threads about what was in scope
> > - there is some development efforts required to review/merge/update these
> > patches and we are trying to release
> > - the change is unintrusive
> > - this is a change to the protocol
> >
> > Not having this doesnt effect me for $dayJob, but I want to reiterate
> that
> > it's a silly thing to leave to clients. Given we've previously scoped it
> to
> > 4.0, im still +1 on adding it.
> >
> > It's ok to have differing opinions. I'd like to see us disagree and
> commit
> > to a course of action either way as opposed to just letting it sit more
> > because we can't sort it out.
> >
>
Re: server side describe
Posted by Jon Haddad <jo...@jonhaddad.com>.
Chris's original patch used a virtual table which didn't even require a
protocol change. To me, the difference between having a CQL describe vs a
virtual table is unimportant, since it's only drivers that need to care
about it. I'm completely fine with the simpler implementation of a virtual
table.
Quite a bit of Chris's patch also fixes our broken server side CQL
generation, something that affects correctness in our snapshots. So either
way most of the code needs to go in before we release 4.0. Adding a single
file that creates a new virtual table is so trivial I'm having a hard time
understanding the opposition.
On Thu, Apr 2, 2020 at 12:56 PM Nate McCall <zz...@gmail.com> wrote:
> So summarizing the salient points here:
> - client authors have worked around this mostly, but this would avoid some
> duplication of effort for new features
> - this issues was tagged last year as being pertinent to 4.0 in several
> threads about what was in scope
> - there is some development efforts required to review/merge/update these
> patches and we are trying to release
> - the change is unintrusive
> - this is a change to the protocol
>
> Not having this doesnt effect me for $dayJob, but I want to reiterate that
> it's a silly thing to leave to clients. Given we've previously scoped it to
> 4.0, im still +1 on adding it.
>
> It's ok to have differing opinions. I'd like to see us disagree and commit
> to a course of action either way as opposed to just letting it sit more
> because we can't sort it out.
>
Re: server side describe
Posted by Nate McCall <zz...@gmail.com>.
So summarizing the salient points here:
- client authors have worked around this mostly, but this would avoid some
duplication of effort for new features
- this issues was tagged last year as being pertinent to 4.0 in several
threads about what was in scope
- there is some development efforts required to review/merge/update these
patches and we are trying to release
- the change is unintrusive
- this is a change to the protocol
Not having this doesnt effect me for $dayJob, but I want to reiterate that
it's a silly thing to leave to clients. Given we've previously scoped it to
4.0, im still +1 on adding it.
It's ok to have differing opinions. I'd like to see us disagree and commit
to a course of action either way as opposed to just letting it sit more
because we can't sort it out.
Re: server side describe
Posted by Aleksey Yeshchenko <al...@apple.com.INVALID>.
Yeah, I feel like it’s a bad example to use to highlight 4.0 scope creep (which is less of a thing than some fear).
The work there is already done, and it’s extremely unintrusive. There is no reason whatsoever to block 4.0 on it, but no reason not to commit - now, in a beta, in the first RC, or even later in a minor.
> On 2 Apr 2020, at 17:40, Benedict Elliott Smith <be...@apache.org> wrote:
>
> Sorry if this is a repeat message; I messed up my mail client settings (I don't see it today, but it might just be stuck in an unmonitored moderator queue):
>
> I think it is unfair to label this scope creep; it would have to be newly considered for 4.0 for it to fall under that umbrella, surely?
>
> I don't personally mind if it lands, but this was discussed at length on multiple occasions over the past year, and only stalled because of a combination of lack of etiquette, and a lack of leadership from e.g. PMC in resolving various primarily political questions over the course of events.
>
> I also struggle to see how this would invalidate testing in any significant way? It doesn't modify any existing behaviour.
>
>
> On 02/04/2020, 09:08, "Benjamin Lerer" <be...@datastax.com> wrote:
>
> +1 for shipping it after 4.0
>
>
>
> On Thu, Apr 2, 2020 at 12:39 AM Jon Haddad <jo...@jonhaddad.com> wrote:
>
>> Most of the work to provide this feature is already done. We need to
>> generate server side CQL for snapshots already. All we need to do is
>> expose it via either a "DESCRIBE" CQL command, or I'm equally happy to see
>> it land in a virtual table.
>>
>> On Wed, Apr 1, 2020 at 2:45 PM sankalp kohli <ko...@gmail.com>
>> wrote:
>>
>>> +1 on holding off and focus on shipping 4.0
>>>
>>> On Wed, Apr 1, 2020 at 12:25 PM Joshua McKenzie <jm...@apache.org>
>>> wrote:
>>>
>>>> This looks like a feature that'd potentially invalidate some testing
>>> that's
>>>> been done and we've been feature frozen for over a year and a half.
>> Also:
>>>> scope creep.
>>>>
>>>> My PoV is we hold off. If we get into a cadence of more frequent
>> releases
>>>> we'll have it soon enough.
>>>>
>>>> On Wed, Apr 1, 2020 at 3:03 PM <e....@gmail.com> wrote:
>>>>
>>>>> Hi,
>>>>> Normally I ping the person on the ticket or in Slack to ask him/her
>> for
>>>>> status update and whether I can help. Then probably he/she gives me a
>>>>> direction.
>>>>> If I can’t find the person anymore, I just use my best judgement and
>>>>> coordinate with people who might know better than me.
>>>>> For now this strategy worked for me personally.
>>>>> Hope this helps
>>>>> Ekaterina
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>>> On 1 Apr 2020, at 14:27, Jon Haddad <jo...@jonhaddad.com> wrote:
>>>>>>
>>>>>> Hey folks,
>>>>>>
>>>>>> I was looking through our open JIRAs and realized we hadn't merged
>> in
>>>>>> server side describe calls yet. The ticket died off a ways ago,
>> and
>>> I
>>>>>> pinged Chris about it yesterday. He's got a lot of his plate and
>>> won't
>>>>> be
>>>>>> able to work on it anytime soon. I still think we should include
>>> this
>>>> in
>>>>>> 4.0.
>>>>>>
>>>>>> From a technical standpoint, It doesn't say much on the ticket
>> after
>>>>> Robert
>>>>>> tossed an alternative patch out there. I don't mind reviewing and
>>>>> merging
>>>>>> either of them, it sounded like both are pretty close to done and I
>>>> think
>>>>>> from the perspective of updating drivers for 4.0 this will save
>>> quite a
>>>>> bit
>>>>>> of time since driver maintainers won't have to add new CQL
>> generation
>>>> for
>>>>>> the various new options that have recently appeared.
>>>>>>
>>>>>> Questions:
>>>>>>
>>>>>> * Does anyone have an objection to getting this into 4.0? The
>> patches
>>>>>> aren't too huge, I think they're low risk, and also fairly high
>>> reward.
>>>>>> * I don't have an opinion (yet) on Robert's patch vs Chris's, with
>>>> regard
>>>>>> to which is preferable.
>>>>>> * Since soon after Robert put up his PR he hasn't been around, at
>>> least
>>>>> as
>>>>>> far as I've seen. How have we dealt with abandoned patches before?
>>> If
>>>>>> we're going to add this in the patch will need some cleanup. Is it
>>>>>> reasonable to continue someone else's work when they've
>> disappeared?
>>>>>>
>>>>>> Jon
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>
>>>>>
>>>>
>>>
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: server side describe
Posted by Benedict Elliott Smith <be...@apache.org>.
Sorry if this is a repeat message; I messed up my mail client settings (I don't see it today, but it might just be stuck in an unmonitored moderator queue):
I think it is unfair to label this scope creep; it would have to be newly considered for 4.0 for it to fall under that umbrella, surely?
I don't personally mind if it lands, but this was discussed at length on multiple occasions over the past year, and only stalled because of a combination of lack of etiquette, and a lack of leadership from e.g. PMC in resolving various primarily political questions over the course of events.
I also struggle to see how this would invalidate testing in any significant way? It doesn't modify any existing behaviour.
On 02/04/2020, 09:08, "Benjamin Lerer" <be...@datastax.com> wrote:
+1 for shipping it after 4.0
On Thu, Apr 2, 2020 at 12:39 AM Jon Haddad <jo...@jonhaddad.com> wrote:
> Most of the work to provide this feature is already done. We need to
> generate server side CQL for snapshots already. All we need to do is
> expose it via either a "DESCRIBE" CQL command, or I'm equally happy to see
> it land in a virtual table.
>
> On Wed, Apr 1, 2020 at 2:45 PM sankalp kohli <ko...@gmail.com>
> wrote:
>
> > +1 on holding off and focus on shipping 4.0
> >
> > On Wed, Apr 1, 2020 at 12:25 PM Joshua McKenzie <jm...@apache.org>
> > wrote:
> >
> > > This looks like a feature that'd potentially invalidate some testing
> > that's
> > > been done and we've been feature frozen for over a year and a half.
> Also:
> > > scope creep.
> > >
> > > My PoV is we hold off. If we get into a cadence of more frequent
> releases
> > > we'll have it soon enough.
> > >
> > > On Wed, Apr 1, 2020 at 3:03 PM <e....@gmail.com> wrote:
> > >
> > > > Hi,
> > > > Normally I ping the person on the ticket or in Slack to ask him/her
> for
> > > > status update and whether I can help. Then probably he/she gives me a
> > > > direction.
> > > > If I can’t find the person anymore, I just use my best judgement and
> > > > coordinate with people who might know better than me.
> > > > For now this strategy worked for me personally.
> > > > Hope this helps
> > > > Ekaterina
> > > >
> > > > Sent from my iPhone
> > > >
> > > > > On 1 Apr 2020, at 14:27, Jon Haddad <jo...@jonhaddad.com> wrote:
> > > > >
> > > > > Hey folks,
> > > > >
> > > > > I was looking through our open JIRAs and realized we hadn't merged
> in
> > > > > server side describe calls yet. The ticket died off a ways ago,
> and
> > I
> > > > > pinged Chris about it yesterday. He's got a lot of his plate and
> > won't
> > > > be
> > > > > able to work on it anytime soon. I still think we should include
> > this
> > > in
> > > > > 4.0.
> > > > >
> > > > > From a technical standpoint, It doesn't say much on the ticket
> after
> > > > Robert
> > > > > tossed an alternative patch out there. I don't mind reviewing and
> > > > merging
> > > > > either of them, it sounded like both are pretty close to done and I
> > > think
> > > > > from the perspective of updating drivers for 4.0 this will save
> > quite a
> > > > bit
> > > > > of time since driver maintainers won't have to add new CQL
> generation
> > > for
> > > > > the various new options that have recently appeared.
> > > > >
> > > > > Questions:
> > > > >
> > > > > * Does anyone have an objection to getting this into 4.0? The
> patches
> > > > > aren't too huge, I think they're low risk, and also fairly high
> > reward.
> > > > > * I don't have an opinion (yet) on Robert's patch vs Chris's, with
> > > regard
> > > > > to which is preferable.
> > > > > * Since soon after Robert put up his PR he hasn't been around, at
> > least
> > > > as
> > > > > far as I've seen. How have we dealt with abandoned patches before?
> > If
> > > > > we're going to add this in the patch will need some cleanup. Is it
> > > > > reasonable to continue someone else's work when they've
> disappeared?
> > > > >
> > > > > Jon
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > > > For additional commands, e-mail: dev-help@cassandra.apache.org
> > > >
> > > >
> > >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: server side describe
Posted by Benjamin Lerer <be...@datastax.com>.
+1 for shipping it after 4.0
On Thu, Apr 2, 2020 at 12:39 AM Jon Haddad <jo...@jonhaddad.com> wrote:
> Most of the work to provide this feature is already done. We need to
> generate server side CQL for snapshots already. All we need to do is
> expose it via either a "DESCRIBE" CQL command, or I'm equally happy to see
> it land in a virtual table.
>
> On Wed, Apr 1, 2020 at 2:45 PM sankalp kohli <ko...@gmail.com>
> wrote:
>
> > +1 on holding off and focus on shipping 4.0
> >
> > On Wed, Apr 1, 2020 at 12:25 PM Joshua McKenzie <jm...@apache.org>
> > wrote:
> >
> > > This looks like a feature that'd potentially invalidate some testing
> > that's
> > > been done and we've been feature frozen for over a year and a half.
> Also:
> > > scope creep.
> > >
> > > My PoV is we hold off. If we get into a cadence of more frequent
> releases
> > > we'll have it soon enough.
> > >
> > > On Wed, Apr 1, 2020 at 3:03 PM <e....@gmail.com> wrote:
> > >
> > > > Hi,
> > > > Normally I ping the person on the ticket or in Slack to ask him/her
> for
> > > > status update and whether I can help. Then probably he/she gives me a
> > > > direction.
> > > > If I can’t find the person anymore, I just use my best judgement and
> > > > coordinate with people who might know better than me.
> > > > For now this strategy worked for me personally.
> > > > Hope this helps
> > > > Ekaterina
> > > >
> > > > Sent from my iPhone
> > > >
> > > > > On 1 Apr 2020, at 14:27, Jon Haddad <jo...@jonhaddad.com> wrote:
> > > > >
> > > > > Hey folks,
> > > > >
> > > > > I was looking through our open JIRAs and realized we hadn't merged
> in
> > > > > server side describe calls yet. The ticket died off a ways ago,
> and
> > I
> > > > > pinged Chris about it yesterday. He's got a lot of his plate and
> > won't
> > > > be
> > > > > able to work on it anytime soon. I still think we should include
> > this
> > > in
> > > > > 4.0.
> > > > >
> > > > > From a technical standpoint, It doesn't say much on the ticket
> after
> > > > Robert
> > > > > tossed an alternative patch out there. I don't mind reviewing and
> > > > merging
> > > > > either of them, it sounded like both are pretty close to done and I
> > > think
> > > > > from the perspective of updating drivers for 4.0 this will save
> > quite a
> > > > bit
> > > > > of time since driver maintainers won't have to add new CQL
> generation
> > > for
> > > > > the various new options that have recently appeared.
> > > > >
> > > > > Questions:
> > > > >
> > > > > * Does anyone have an objection to getting this into 4.0? The
> patches
> > > > > aren't too huge, I think they're low risk, and also fairly high
> > reward.
> > > > > * I don't have an opinion (yet) on Robert's patch vs Chris's, with
> > > regard
> > > > > to which is preferable.
> > > > > * Since soon after Robert put up his PR he hasn't been around, at
> > least
> > > > as
> > > > > far as I've seen. How have we dealt with abandoned patches before?
> > If
> > > > > we're going to add this in the patch will need some cleanup. Is it
> > > > > reasonable to continue someone else's work when they've
> disappeared?
> > > > >
> > > > > Jon
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > > > For additional commands, e-mail: dev-help@cassandra.apache.org
> > > >
> > > >
> > >
> >
>
Re: server side describe
Posted by Jon Haddad <jo...@jonhaddad.com>.
Most of the work to provide this feature is already done. We need to
generate server side CQL for snapshots already. All we need to do is
expose it via either a "DESCRIBE" CQL command, or I'm equally happy to see
it land in a virtual table.
On Wed, Apr 1, 2020 at 2:45 PM sankalp kohli <ko...@gmail.com> wrote:
> +1 on holding off and focus on shipping 4.0
>
> On Wed, Apr 1, 2020 at 12:25 PM Joshua McKenzie <jm...@apache.org>
> wrote:
>
> > This looks like a feature that'd potentially invalidate some testing
> that's
> > been done and we've been feature frozen for over a year and a half. Also:
> > scope creep.
> >
> > My PoV is we hold off. If we get into a cadence of more frequent releases
> > we'll have it soon enough.
> >
> > On Wed, Apr 1, 2020 at 3:03 PM <e....@gmail.com> wrote:
> >
> > > Hi,
> > > Normally I ping the person on the ticket or in Slack to ask him/her for
> > > status update and whether I can help. Then probably he/she gives me a
> > > direction.
> > > If I can’t find the person anymore, I just use my best judgement and
> > > coordinate with people who might know better than me.
> > > For now this strategy worked for me personally.
> > > Hope this helps
> > > Ekaterina
> > >
> > > Sent from my iPhone
> > >
> > > > On 1 Apr 2020, at 14:27, Jon Haddad <jo...@jonhaddad.com> wrote:
> > > >
> > > > Hey folks,
> > > >
> > > > I was looking through our open JIRAs and realized we hadn't merged in
> > > > server side describe calls yet. The ticket died off a ways ago, and
> I
> > > > pinged Chris about it yesterday. He's got a lot of his plate and
> won't
> > > be
> > > > able to work on it anytime soon. I still think we should include
> this
> > in
> > > > 4.0.
> > > >
> > > > From a technical standpoint, It doesn't say much on the ticket after
> > > Robert
> > > > tossed an alternative patch out there. I don't mind reviewing and
> > > merging
> > > > either of them, it sounded like both are pretty close to done and I
> > think
> > > > from the perspective of updating drivers for 4.0 this will save
> quite a
> > > bit
> > > > of time since driver maintainers won't have to add new CQL generation
> > for
> > > > the various new options that have recently appeared.
> > > >
> > > > Questions:
> > > >
> > > > * Does anyone have an objection to getting this into 4.0? The patches
> > > > aren't too huge, I think they're low risk, and also fairly high
> reward.
> > > > * I don't have an opinion (yet) on Robert's patch vs Chris's, with
> > regard
> > > > to which is preferable.
> > > > * Since soon after Robert put up his PR he hasn't been around, at
> least
> > > as
> > > > far as I've seen. How have we dealt with abandoned patches before?
> If
> > > > we're going to add this in the patch will need some cleanup. Is it
> > > > reasonable to continue someone else's work when they've disappeared?
> > > >
> > > > Jon
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > > For additional commands, e-mail: dev-help@cassandra.apache.org
> > >
> > >
> >
>
Re: server side describe
Posted by sankalp kohli <ko...@gmail.com>.
+1 on holding off and focus on shipping 4.0
On Wed, Apr 1, 2020 at 12:25 PM Joshua McKenzie <jm...@apache.org>
wrote:
> This looks like a feature that'd potentially invalidate some testing that's
> been done and we've been feature frozen for over a year and a half. Also:
> scope creep.
>
> My PoV is we hold off. If we get into a cadence of more frequent releases
> we'll have it soon enough.
>
> On Wed, Apr 1, 2020 at 3:03 PM <e....@gmail.com> wrote:
>
> > Hi,
> > Normally I ping the person on the ticket or in Slack to ask him/her for
> > status update and whether I can help. Then probably he/she gives me a
> > direction.
> > If I can’t find the person anymore, I just use my best judgement and
> > coordinate with people who might know better than me.
> > For now this strategy worked for me personally.
> > Hope this helps
> > Ekaterina
> >
> > Sent from my iPhone
> >
> > > On 1 Apr 2020, at 14:27, Jon Haddad <jo...@jonhaddad.com> wrote:
> > >
> > > Hey folks,
> > >
> > > I was looking through our open JIRAs and realized we hadn't merged in
> > > server side describe calls yet. The ticket died off a ways ago, and I
> > > pinged Chris about it yesterday. He's got a lot of his plate and won't
> > be
> > > able to work on it anytime soon. I still think we should include this
> in
> > > 4.0.
> > >
> > > From a technical standpoint, It doesn't say much on the ticket after
> > Robert
> > > tossed an alternative patch out there. I don't mind reviewing and
> > merging
> > > either of them, it sounded like both are pretty close to done and I
> think
> > > from the perspective of updating drivers for 4.0 this will save quite a
> > bit
> > > of time since driver maintainers won't have to add new CQL generation
> for
> > > the various new options that have recently appeared.
> > >
> > > Questions:
> > >
> > > * Does anyone have an objection to getting this into 4.0? The patches
> > > aren't too huge, I think they're low risk, and also fairly high reward.
> > > * I don't have an opinion (yet) on Robert's patch vs Chris's, with
> regard
> > > to which is preferable.
> > > * Since soon after Robert put up his PR he hasn't been around, at least
> > as
> > > far as I've seen. How have we dealt with abandoned patches before? If
> > > we're going to add this in the patch will need some cleanup. Is it
> > > reasonable to continue someone else's work when they've disappeared?
> > >
> > > Jon
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
> >
>
Re: server side describe
Posted by Dinesh Joshi <dj...@apache.org>.
I'll volunteer.
Dinesh
> On Apr 16, 2020, at 12:47 AM, Benjamin Lerer <be...@datastax.com> wrote:
>
> Now that there is an agreement on having this patch on 4.0. I would like to
> see it done as soon as possible. It would minimize the risks by giving us
> more testing time. It will also give the driver developers a chance to use
> it and provide feedback if they hit some issues.
>
> Robert rebased his patch yesterday and I started to review it. If somebody
> else want to give another look to the patch, I am 100% for it.
>
>
>
>
> On Wed, Apr 15, 2020 at 7:48 PM Jon Haddad <jo...@jonhaddad.com> wrote:
>
>> I don't think we need to vote on this. A few folks have expressed (very
>> justified) concern, but nobody has gone nuclear.
>>
>> I intended on cleaning up the patch and getting it ready for another
>> review, but haven't had it in my brain and have been busy with other
>> things. I don't claim exclusive rights to the clean up patch, if someone
>> was motivated to do it I'd be 100% fine with it. :)
>>
>>
>>
>>
>> On Wed, Apr 15, 2020 at 10:15 AM sankalp kohli <ko...@gmail.com>
>> wrote:
>>
>>> What are the next steps? Do we hold a vote as I see few initial emails
>>> which dont seem to agree and have not replied based on future
>> discussions.
>>>
>>> On Fri, Apr 10, 2020 at 12:50 PM Dinesh Joshi <dj...@apache.org> wrote:
>>>
>>>> +1 let's keep moving forward.
>>>>
>>>> Dinesh
>>>>
>>>>> On Apr 9, 2020, at 4:07 PM, Nate McCall <zz...@gmail.com> wrote:
>>>>>
>>>>> Ok cool. It sounds like we are moving this towards a consensus? (at
>>> least
>>>>> agreeing to disagree and moving forward).
>>>>>
>>>>> I very much the different inputs on this thread - thanks for a
>> largely
>>>>> healthy discussion folks.
>>>>>
>>>>> On Fri, Apr 10, 2020 at 6:03 AM Chris Lohfink <cl...@gmail.com>
>>>> wrote:
>>>>>
>>>>>> I'd be in favor of going with the newer DESCRIBE option. The
>> original
>>>> patch
>>>>>> was mostly focused on just getting the CQL correct and used virtual
>>>> tables
>>>>>> because its what the initial feedback was to do. Robert added a lot
>> of
>>>>>> functionality on top of what was there which is what people were
>>>> starting
>>>>>> to ask for. I am in favor of just going off of his patch and moving
>>>>>> forward. I initially heard post 4.0 so I know I haven't been focused
>>> on
>>>> it
>>>>>> but if theres desire to put it in 4.0 I am +1 on it and would like
>> to
>>>> see
>>>>>> just going off of the Robert's latest patch.
>>>>>>
>>>>>> Chris
>>>>>>
>>>>>> On Thu, Apr 9, 2020 at 6:41 AM Benjamin Lerer <
>>>> benjamin.lerer@datastax.com
>>>>>>>
>>>>>> wrote:
>>>>>>
>>>>>>> Thanks for your answer Alex.
>>>>>>>
>>>>>>> Some of the things we
>>>>>>>> have explicitly (as a community) agreed to commit are still in
>>>>>> progress,
>>>>>>>> including several client protocol changes. And, to my
>> understanding,
>>>> if
>>>>>>>> those are committed, it'll be what community has agreed upon.
>>>>>>>>
>>>>>>>
>>>>>>> If the understanding of the community was that this patch was
>>> expected
>>>> to
>>>>>>> go in 4.0 then it makes sense to commit it there.
>>>>>>>
>>>>>>>
>>>>>>>> If the discussion is about whether or not to include _some_
>> version
>>> of
>>>>>>> the
>>>>>>>> patch, I think including it makes sense, especially given the
>> patch
>>>> was
>>>>>>>> there for a while and was not committed for non-technical reasons.
>>> If
>>>>>>> we're
>>>>>>>> trying to decide _which_ patch to commit, I'd personally focus on
>>> the
>>>>>>>> original patch (to foster recognition), get it reviewed, and pick
>>> any
>>>>>>>> changes that make it better from the follow-up one (to foster
>>>>>>>> collaboration).
>>>>>>>>
>>>>>>>
>>>>>>> I am fine going through both patches and figuring out a way to
>> merge
>>>> them
>>>>>>> into one if Jon or somebody else is willing to review the output of
>>>> that
>>>>>>> merge
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Apr 9, 2020 at 12:45 PM Benedict Elliott Smith <
>>>>>>> benedict@apache.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> +1 all of this
>>>>>>>>
>>>>>>>> On 09/04/2020, 10:23, "Oleksandr Petrov" <
>>> oleksandr.petrov@gmail.com
>>>>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> My understanding is that a majority of people ended up in favor
>>>>>> of
>>>>>>>> a DESCRIBE approach. Robert made a patch for that approach
>>>>>> (according
>>>>>>>> to
>>>>>>>> his comment it was discussed with Chris beforehand).
>>>>>>>>
>>>>>>>> This sounds like just a switch of API (in other words, you use
>>> the
>>>>>>> same
>>>>>>>> string generation, but return it via different means). From the
>>>>>>>> (little)
>>>>>>>> time I've spent looking at the patch, I remember that there
>>> wasn't
>>>>>>> much
>>>>>>>> common code between the two (sorry if I'm remembering it
>> wrong).
>>>>>>>>
>>>>>>>> If the discussion is about whether or not to include _some_
>>> version
>>>>>>> of
>>>>>>>> the
>>>>>>>> patch, I think including it makes sense, especially given the
>>> patch
>>>>>>> was
>>>>>>>> there for a while and was not committed for non-technical
>>> reasons.
>>>>>> If
>>>>>>>> we're
>>>>>>>> trying to decide _which_ patch to commit, I'd personally focus
>> on
>>>>>> the
>>>>>>>> original patch (to foster recognition), get it reviewed, and
>> pick
>>>>>> any
>>>>>>>> changes that make it better from the follow-up one (to foster
>>>>>>>> collaboration).
>>>>>>>>
>>>>>>>>> Where do we draw the line?
>>>>>>>>
>>>>>>>> I would discuss changes on the case-by-case basis. Some of the
>>>>>> things
>>>>>>>> we
>>>>>>>> have explicitly (as a community) agreed to commit are still in
>>>>>>>> progress,
>>>>>>>> including several client protocol changes. And, to my
>>>>>> understanding,
>>>>>>> if
>>>>>>>> those are committed, it'll be what community has agreed upon.
>> All
>>>>>>>> further
>>>>>>>> changes that weren't discussed yet - we can talk over. If it's
>>>>>>>> something as
>>>>>>>> trivial as server-side describe that doesn't risk stability but
>>>>>> adds
>>>>>>> a
>>>>>>>> lot
>>>>>>>> of value, it may make sense to include. But I woudln't attempt
>> to
>>>>>>> come
>>>>>>>> up
>>>>>>>> with a general rule for what we may or may not consider for
>> now.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Apr 6, 2020 at 3:21 PM Benjamin Lerer <
>>>>>>>> benjamin.lerer@datastax.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> We have already discussed it for several days and I believe that
>>>>>>> all
>>>>>>>> the
>>>>>>>>> points have been brought to the table.
>>>>>>>>>
>>>>>>>>> I took the time to read CASSANDRA-14825 this morning to
>>>>>> understand
>>>>>>>> the full
>>>>>>>>> story.
>>>>>>>>> All the discussion has been about using Virtual Tables versus
>>>>>> using
>>>>>>>>> DESCRIBE.
>>>>>>>>> My understanding is that a majority of people ended up in favor
>>>>>> of
>>>>>>> a
>>>>>>>>> DESCRIBE approach (skipping the details on purpose here).
>>>>>>>>> Robert made a patch for that approach (according to his comment
>>>>>> it
>>>>>>>> was
>>>>>>>>> discussed with Chris beforehand).
>>>>>>>>>
>>>>>>>>> The question here is should: we agree to put it in 4.0 even if
>>>>>> the
>>>>>>>> version
>>>>>>>>> is frozen for improvements.
>>>>>>>>>
>>>>>>>>> My main reason against it is that if we broke the freeze for
>>>>>> every
>>>>>>>> ticket
>>>>>>>>> we believe might be useful we will end up delaying 4.0 a lot.
>>>>>>>>> Are there not other tickets that are more valuable than
>>>>>>>> CASSANDRA-14825,
>>>>>>>>> that are not included in 4.0?
>>>>>>>>> Where do we draw the line?
>>>>>>>>>
>>>>>>>>> I believe that if we were able to answer that question it would
>>>>>>>> suddenly
>>>>>>>>> become much easier to agree on which tickets we put in 4.0.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sun, Apr 5, 2020 at 1:25 AM Benedict Elliott Smith <
>>>>>>>> benedict@apache.org
>>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> There it is. I knew it would show up eventually.
>>>>>>>>>>
>>>>>>>>>> On 04/04/2020, 06:26, "benedict@apache.org" <
>>>>>>>> public@belliottsmith.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> scope creep.
>>>>>>>>>>
>>>>>>>>>> I think it is unfair to label this scope creep; it would
>>>>>> have
>>>>>>>> to be
>>>>>>>>>> newly considered for 4.0 for it to fall under that umbrella.
>>>>>>>>>>
>>>>>>>>>> I don't personally mind if it lands, but this was discussed
>>>>>>> at
>>>>>>>> length
>>>>>>>>>> on multiple occasions over the past year, and only stalled
>>>>>>> because
>>>>>>>> of a
>>>>>>>>>> combination of lack of etiquette, and a lack of leadership from
>>>>>>>> e.g. PMC
>>>>>>>>> in
>>>>>>>>>> resolving various political questions over the course of
>>>>>> events.
>>>>>>>>>>
>>>>>>>>>> I also struggle to see how this would invalidate testing in
>>>>>>> any
>>>>>>>>>> significant way? It doesn't modify any existing behaviour.
>>>>>>>>>>
>>>>>>>>>> ________________________________
>>>>>>>>>> From: Joshua McKenzie <jm...@apache.org>
>>>>>>>>>> Sent: 01 April 2020 19:24
>>>>>>>>>> To: dev@cassandra.apache.org <de...@cassandra.apache.org>
>>>>>>>>>> Subject: Re: server side describe
>>>>>>>>>>
>>>>>>>>>> This looks like a feature that'd potentially invalidate
>>>>>> some
>>>>>>>> testing
>>>>>>>>>> that's
>>>>>>>>>> been done and we've been feature frozen for over a year
>>>>>> and a
>>>>>>>> half.
>>>>>>>>>> Also:
>>>>>>>>>> scope creep.
>>>>>>>>>>
>>>>>>>>>> My PoV is we hold off. If we get into a cadence of more
>>>>>>>> frequent
>>>>>>>>>> releases
>>>>>>>>>> we'll have it soon enough.
>>>>>>>>>>
>>>>>>>>>> On Wed, Apr 1, 2020 at 3:03 PM <e....@gmail.com>
>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>> Normally I ping the person on the ticket or in Slack to
>>>>>> ask
>>>>>>>> him/her
>>>>>>>>>> for
>>>>>>>>>>> status update and whether I can help. Then probably
>>>>>> he/she
>>>>>>>> gives
>>>>>>>>> me a
>>>>>>>>>>> direction.
>>>>>>>>>>> If I can’t find the person anymore, I just use my best
>>>>>>>> judgement
>>>>>>>>> and
>>>>>>>>>>> coordinate with people who might know better than me.
>>>>>>>>>>> For now this strategy worked for me personally.
>>>>>>>>>>> Hope this helps
>>>>>>>>>>> Ekaterina
>>>>>>>>>>>
>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>
>>>>>>>>>>>> On 1 Apr 2020, at 14:27, Jon Haddad <jon@jonhaddad.com
>>>>>>>
>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hey folks,
>>>>>>>>>>>>
>>>>>>>>>>>> I was looking through our open JIRAs and realized we
>>>>>>> hadn't
>>>>>>>>> merged
>>>>>>>>>> in
>>>>>>>>>>>> server side describe calls yet. The ticket died off a
>>>>>>>> ways ago,
>>>>>>>>>> and I
>>>>>>>>>>>> pinged Chris about it yesterday. He's got a lot of his
>>>>>>>> plate and
>>>>>>>>>> won't
>>>>>>>>>>> be
>>>>>>>>>>>> able to work on it anytime soon. I still think we
>>>>>> should
>>>>>>>> include
>>>>>>>>>> this in
>>>>>>>>>>>> 4.0.
>>>>>>>>>>>>
>>>>>>>>>>>> From a technical standpoint, It doesn't say much on the
>>>>>>>> ticket
>>>>>>>>>> after
>>>>>>>>>>> Robert
>>>>>>>>>>>> tossed an alternative patch out there. I don't mind
>>>>>>>> reviewing
>>>>>>>>> and
>>>>>>>>>>> merging
>>>>>>>>>>>> either of them, it sounded like both are pretty close
>>>>>> to
>>>>>>>> done and
>>>>>>>>>> I think
>>>>>>>>>>>> from the perspective of updating drivers for 4.0 this
>>>>>>> will
>>>>>>>> save
>>>>>>>>>> quite a
>>>>>>>>>>> bit
>>>>>>>>>>>> of time since driver maintainers won't have to add new
>>>>>>> CQL
>>>>>>>>>> generation for
>>>>>>>>>>>> the various new options that have recently appeared.
>>>>>>>>>>>>
>>>>>>>>>>>> Questions:
>>>>>>>>>>>>
>>>>>>>>>>>> * Does anyone have an objection to getting this into
>>>>>> 4.0?
>>>>>>>> The
>>>>>>>>>> patches
>>>>>>>>>>>> aren't too huge, I think they're low risk, and also
>>>>>>> fairly
>>>>>>>> high
>>>>>>>>>> reward.
>>>>>>>>>>>> * I don't have an opinion (yet) on Robert's patch vs
>>>>>>>> Chris's,
>>>>>>>>> with
>>>>>>>>>> regard
>>>>>>>>>>>> to which is preferable.
>>>>>>>>>>>> * Since soon after Robert put up his PR he hasn't been
>>>>>>>> around, at
>>>>>>>>>> least
>>>>>>>>>>> as
>>>>>>>>>>>> far as I've seen. How have we dealt with abandoned
>>>>>>> patches
>>>>>>>>>> before? If
>>>>>>>>>>>> we're going to add this in the patch will need some
>>>>>>>> cleanup. Is
>>>>>>>>> it
>>>>>>>>>>>> reasonable to continue someone else's work when they've
>>>>>>>>>> disappeared?
>>>>>>>>>>>>
>>>>>>>>>>>> Jon
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail:
>>>>>>> dev-unsubscribe@cassandra.apache.org
>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>> dev-help@cassandra.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> alex p
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>
>>>>
>>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: server side describe
Posted by Benjamin Lerer <be...@datastax.com>.
Now that there is an agreement on having this patch on 4.0. I would like to
see it done as soon as possible. It would minimize the risks by giving us
more testing time. It will also give the driver developers a chance to use
it and provide feedback if they hit some issues.
Robert rebased his patch yesterday and I started to review it. If somebody
else want to give another look to the patch, I am 100% for it.
On Wed, Apr 15, 2020 at 7:48 PM Jon Haddad <jo...@jonhaddad.com> wrote:
> I don't think we need to vote on this. A few folks have expressed (very
> justified) concern, but nobody has gone nuclear.
>
> I intended on cleaning up the patch and getting it ready for another
> review, but haven't had it in my brain and have been busy with other
> things. I don't claim exclusive rights to the clean up patch, if someone
> was motivated to do it I'd be 100% fine with it. :)
>
>
>
>
> On Wed, Apr 15, 2020 at 10:15 AM sankalp kohli <ko...@gmail.com>
> wrote:
>
> > What are the next steps? Do we hold a vote as I see few initial emails
> > which dont seem to agree and have not replied based on future
> discussions.
> >
> > On Fri, Apr 10, 2020 at 12:50 PM Dinesh Joshi <dj...@apache.org> wrote:
> >
> > > +1 let's keep moving forward.
> > >
> > > Dinesh
> > >
> > > > On Apr 9, 2020, at 4:07 PM, Nate McCall <zz...@gmail.com> wrote:
> > > >
> > > > Ok cool. It sounds like we are moving this towards a consensus? (at
> > least
> > > > agreeing to disagree and moving forward).
> > > >
> > > > I very much the different inputs on this thread - thanks for a
> largely
> > > > healthy discussion folks.
> > > >
> > > > On Fri, Apr 10, 2020 at 6:03 AM Chris Lohfink <cl...@gmail.com>
> > > wrote:
> > > >
> > > >> I'd be in favor of going with the newer DESCRIBE option. The
> original
> > > patch
> > > >> was mostly focused on just getting the CQL correct and used virtual
> > > tables
> > > >> because its what the initial feedback was to do. Robert added a lot
> of
> > > >> functionality on top of what was there which is what people were
> > > starting
> > > >> to ask for. I am in favor of just going off of his patch and moving
> > > >> forward. I initially heard post 4.0 so I know I haven't been focused
> > on
> > > it
> > > >> but if theres desire to put it in 4.0 I am +1 on it and would like
> to
> > > see
> > > >> just going off of the Robert's latest patch.
> > > >>
> > > >> Chris
> > > >>
> > > >> On Thu, Apr 9, 2020 at 6:41 AM Benjamin Lerer <
> > > benjamin.lerer@datastax.com
> > > >>>
> > > >> wrote:
> > > >>
> > > >>> Thanks for your answer Alex.
> > > >>>
> > > >>> Some of the things we
> > > >>>> have explicitly (as a community) agreed to commit are still in
> > > >> progress,
> > > >>>> including several client protocol changes. And, to my
> understanding,
> > > if
> > > >>>> those are committed, it'll be what community has agreed upon.
> > > >>>>
> > > >>>
> > > >>> If the understanding of the community was that this patch was
> > expected
> > > to
> > > >>> go in 4.0 then it makes sense to commit it there.
> > > >>>
> > > >>>
> > > >>>> If the discussion is about whether or not to include _some_
> version
> > of
> > > >>> the
> > > >>>> patch, I think including it makes sense, especially given the
> patch
> > > was
> > > >>>> there for a while and was not committed for non-technical reasons.
> > If
> > > >>> we're
> > > >>>> trying to decide _which_ patch to commit, I'd personally focus on
> > the
> > > >>>> original patch (to foster recognition), get it reviewed, and pick
> > any
> > > >>>> changes that make it better from the follow-up one (to foster
> > > >>>> collaboration).
> > > >>>>
> > > >>>
> > > >>> I am fine going through both patches and figuring out a way to
> merge
> > > them
> > > >>> into one if Jon or somebody else is willing to review the output of
> > > that
> > > >>> merge
> > > >>>
> > > >>>
> > > >>>
> > > >>> On Thu, Apr 9, 2020 at 12:45 PM Benedict Elliott Smith <
> > > >>> benedict@apache.org>
> > > >>> wrote:
> > > >>>
> > > >>>> +1 all of this
> > > >>>>
> > > >>>> On 09/04/2020, 10:23, "Oleksandr Petrov" <
> > oleksandr.petrov@gmail.com
> > > >
> > > >>>> wrote:
> > > >>>>
> > > >>>>> My understanding is that a majority of people ended up in favor
> > > >> of
> > > >>>> a DESCRIBE approach. Robert made a patch for that approach
> > > >> (according
> > > >>>> to
> > > >>>> his comment it was discussed with Chris beforehand).
> > > >>>>
> > > >>>> This sounds like just a switch of API (in other words, you use
> > the
> > > >>> same
> > > >>>> string generation, but return it via different means). From the
> > > >>>> (little)
> > > >>>> time I've spent looking at the patch, I remember that there
> > wasn't
> > > >>> much
> > > >>>> common code between the two (sorry if I'm remembering it
> wrong).
> > > >>>>
> > > >>>> If the discussion is about whether or not to include _some_
> > version
> > > >>> of
> > > >>>> the
> > > >>>> patch, I think including it makes sense, especially given the
> > patch
> > > >>> was
> > > >>>> there for a while and was not committed for non-technical
> > reasons.
> > > >> If
> > > >>>> we're
> > > >>>> trying to decide _which_ patch to commit, I'd personally focus
> on
> > > >> the
> > > >>>> original patch (to foster recognition), get it reviewed, and
> pick
> > > >> any
> > > >>>> changes that make it better from the follow-up one (to foster
> > > >>>> collaboration).
> > > >>>>
> > > >>>>> Where do we draw the line?
> > > >>>>
> > > >>>> I would discuss changes on the case-by-case basis. Some of the
> > > >> things
> > > >>>> we
> > > >>>> have explicitly (as a community) agreed to commit are still in
> > > >>>> progress,
> > > >>>> including several client protocol changes. And, to my
> > > >> understanding,
> > > >>> if
> > > >>>> those are committed, it'll be what community has agreed upon.
> All
> > > >>>> further
> > > >>>> changes that weren't discussed yet - we can talk over. If it's
> > > >>>> something as
> > > >>>> trivial as server-side describe that doesn't risk stability but
> > > >> adds
> > > >>> a
> > > >>>> lot
> > > >>>> of value, it may make sense to include. But I woudln't attempt
> to
> > > >>> come
> > > >>>> up
> > > >>>> with a general rule for what we may or may not consider for
> now.
> > > >>>>
> > > >>>>
> > > >>>> On Mon, Apr 6, 2020 at 3:21 PM Benjamin Lerer <
> > > >>>> benjamin.lerer@datastax.com>
> > > >>>> wrote:
> > > >>>>
> > > >>>>> We have already discussed it for several days and I believe that
> > > >>> all
> > > >>>> the
> > > >>>>> points have been brought to the table.
> > > >>>>>
> > > >>>>> I took the time to read CASSANDRA-14825 this morning to
> > > >> understand
> > > >>>> the full
> > > >>>>> story.
> > > >>>>> All the discussion has been about using Virtual Tables versus
> > > >> using
> > > >>>>> DESCRIBE.
> > > >>>>> My understanding is that a majority of people ended up in favor
> > > >> of
> > > >>> a
> > > >>>>> DESCRIBE approach (skipping the details on purpose here).
> > > >>>>> Robert made a patch for that approach (according to his comment
> > > >> it
> > > >>>> was
> > > >>>>> discussed with Chris beforehand).
> > > >>>>>
> > > >>>>> The question here is should: we agree to put it in 4.0 even if
> > > >> the
> > > >>>> version
> > > >>>>> is frozen for improvements.
> > > >>>>>
> > > >>>>> My main reason against it is that if we broke the freeze for
> > > >> every
> > > >>>> ticket
> > > >>>>> we believe might be useful we will end up delaying 4.0 a lot.
> > > >>>>> Are there not other tickets that are more valuable than
> > > >>>> CASSANDRA-14825,
> > > >>>>> that are not included in 4.0?
> > > >>>>> Where do we draw the line?
> > > >>>>>
> > > >>>>> I believe that if we were able to answer that question it would
> > > >>>> suddenly
> > > >>>>> become much easier to agree on which tickets we put in 4.0.
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>> On Sun, Apr 5, 2020 at 1:25 AM Benedict Elliott Smith <
> > > >>>> benedict@apache.org
> > > >>>>>>
> > > >>>>> wrote:
> > > >>>>>
> > > >>>>>> There it is. I knew it would show up eventually.
> > > >>>>>>
> > > >>>>>> On 04/04/2020, 06:26, "benedict@apache.org" <
> > > >>>> public@belliottsmith.com>
> > > >>>>>> wrote:
> > > >>>>>>
> > > >>>>>>> scope creep.
> > > >>>>>>
> > > >>>>>> I think it is unfair to label this scope creep; it would
> > > >> have
> > > >>>> to be
> > > >>>>>> newly considered for 4.0 for it to fall under that umbrella.
> > > >>>>>>
> > > >>>>>> I don't personally mind if it lands, but this was discussed
> > > >>> at
> > > >>>> length
> > > >>>>>> on multiple occasions over the past year, and only stalled
> > > >>> because
> > > >>>> of a
> > > >>>>>> combination of lack of etiquette, and a lack of leadership from
> > > >>>> e.g. PMC
> > > >>>>> in
> > > >>>>>> resolving various political questions over the course of
> > > >> events.
> > > >>>>>>
> > > >>>>>> I also struggle to see how this would invalidate testing in
> > > >>> any
> > > >>>>>> significant way? It doesn't modify any existing behaviour.
> > > >>>>>>
> > > >>>>>> ________________________________
> > > >>>>>> From: Joshua McKenzie <jm...@apache.org>
> > > >>>>>> Sent: 01 April 2020 19:24
> > > >>>>>> To: dev@cassandra.apache.org <de...@cassandra.apache.org>
> > > >>>>>> Subject: Re: server side describe
> > > >>>>>>
> > > >>>>>> This looks like a feature that'd potentially invalidate
> > > >> some
> > > >>>> testing
> > > >>>>>> that's
> > > >>>>>> been done and we've been feature frozen for over a year
> > > >> and a
> > > >>>> half.
> > > >>>>>> Also:
> > > >>>>>> scope creep.
> > > >>>>>>
> > > >>>>>> My PoV is we hold off. If we get into a cadence of more
> > > >>>> frequent
> > > >>>>>> releases
> > > >>>>>> we'll have it soon enough.
> > > >>>>>>
> > > >>>>>> On Wed, Apr 1, 2020 at 3:03 PM <e....@gmail.com>
> > > >>> wrote:
> > > >>>>>>
> > > >>>>>>> Hi,
> > > >>>>>>> Normally I ping the person on the ticket or in Slack to
> > > >> ask
> > > >>>> him/her
> > > >>>>>> for
> > > >>>>>>> status update and whether I can help. Then probably
> > > >> he/she
> > > >>>> gives
> > > >>>>> me a
> > > >>>>>>> direction.
> > > >>>>>>> If I can’t find the person anymore, I just use my best
> > > >>>> judgement
> > > >>>>> and
> > > >>>>>>> coordinate with people who might know better than me.
> > > >>>>>>> For now this strategy worked for me personally.
> > > >>>>>>> Hope this helps
> > > >>>>>>> Ekaterina
> > > >>>>>>>
> > > >>>>>>> Sent from my iPhone
> > > >>>>>>>
> > > >>>>>>>> On 1 Apr 2020, at 14:27, Jon Haddad <jon@jonhaddad.com
> > > >>>
> > > >>>> wrote:
> > > >>>>>>>>
> > > >>>>>>>> Hey folks,
> > > >>>>>>>>
> > > >>>>>>>> I was looking through our open JIRAs and realized we
> > > >>> hadn't
> > > >>>>> merged
> > > >>>>>> in
> > > >>>>>>>> server side describe calls yet. The ticket died off a
> > > >>>> ways ago,
> > > >>>>>> and I
> > > >>>>>>>> pinged Chris about it yesterday. He's got a lot of his
> > > >>>> plate and
> > > >>>>>> won't
> > > >>>>>>> be
> > > >>>>>>>> able to work on it anytime soon. I still think we
> > > >> should
> > > >>>> include
> > > >>>>>> this in
> > > >>>>>>>> 4.0.
> > > >>>>>>>>
> > > >>>>>>>> From a technical standpoint, It doesn't say much on the
> > > >>>> ticket
> > > >>>>>> after
> > > >>>>>>> Robert
> > > >>>>>>>> tossed an alternative patch out there. I don't mind
> > > >>>> reviewing
> > > >>>>> and
> > > >>>>>>> merging
> > > >>>>>>>> either of them, it sounded like both are pretty close
> > > >> to
> > > >>>> done and
> > > >>>>>> I think
> > > >>>>>>>> from the perspective of updating drivers for 4.0 this
> > > >>> will
> > > >>>> save
> > > >>>>>> quite a
> > > >>>>>>> bit
> > > >>>>>>>> of time since driver maintainers won't have to add new
> > > >>> CQL
> > > >>>>>> generation for
> > > >>>>>>>> the various new options that have recently appeared.
> > > >>>>>>>>
> > > >>>>>>>> Questions:
> > > >>>>>>>>
> > > >>>>>>>> * Does anyone have an objection to getting this into
> > > >> 4.0?
> > > >>>> The
> > > >>>>>> patches
> > > >>>>>>>> aren't too huge, I think they're low risk, and also
> > > >>> fairly
> > > >>>> high
> > > >>>>>> reward.
> > > >>>>>>>> * I don't have an opinion (yet) on Robert's patch vs
> > > >>>> Chris's,
> > > >>>>> with
> > > >>>>>> regard
> > > >>>>>>>> to which is preferable.
> > > >>>>>>>> * Since soon after Robert put up his PR he hasn't been
> > > >>>> around, at
> > > >>>>>> least
> > > >>>>>>> as
> > > >>>>>>>> far as I've seen. How have we dealt with abandoned
> > > >>> patches
> > > >>>>>> before? If
> > > >>>>>>>> we're going to add this in the patch will need some
> > > >>>> cleanup. Is
> > > >>>>> it
> > > >>>>>>>> reasonable to continue someone else's work when they've
> > > >>>>>> disappeared?
> > > >>>>>>>>
> > > >>>>>>>> Jon
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>
> > > >>>
> ---------------------------------------------------------------------
> > > >>>>>>> To unsubscribe, e-mail:
> > > >>> dev-unsubscribe@cassandra.apache.org
> > > >>>>>>> For additional commands, e-mail:
> > > >>>> dev-help@cassandra.apache.org
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>
> > ---------------------------------------------------------------------
> > > >>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > > >>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> > > >>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>>>
> > > >>>> --
> > > >>>> alex p
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > ---------------------------------------------------------------------
> > > >>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > > >>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> > > >>>>
> > > >>>>
> > > >>>
> > > >>
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > > For additional commands, e-mail: dev-help@cassandra.apache.org
> > >
> > >
> >
>
Re: server side describe
Posted by Jon Haddad <jo...@jonhaddad.com>.
I don't think we need to vote on this. A few folks have expressed (very
justified) concern, but nobody has gone nuclear.
I intended on cleaning up the patch and getting it ready for another
review, but haven't had it in my brain and have been busy with other
things. I don't claim exclusive rights to the clean up patch, if someone
was motivated to do it I'd be 100% fine with it. :)
On Wed, Apr 15, 2020 at 10:15 AM sankalp kohli <ko...@gmail.com>
wrote:
> What are the next steps? Do we hold a vote as I see few initial emails
> which dont seem to agree and have not replied based on future discussions.
>
> On Fri, Apr 10, 2020 at 12:50 PM Dinesh Joshi <dj...@apache.org> wrote:
>
> > +1 let's keep moving forward.
> >
> > Dinesh
> >
> > > On Apr 9, 2020, at 4:07 PM, Nate McCall <zz...@gmail.com> wrote:
> > >
> > > Ok cool. It sounds like we are moving this towards a consensus? (at
> least
> > > agreeing to disagree and moving forward).
> > >
> > > I very much the different inputs on this thread - thanks for a largely
> > > healthy discussion folks.
> > >
> > > On Fri, Apr 10, 2020 at 6:03 AM Chris Lohfink <cl...@gmail.com>
> > wrote:
> > >
> > >> I'd be in favor of going with the newer DESCRIBE option. The original
> > patch
> > >> was mostly focused on just getting the CQL correct and used virtual
> > tables
> > >> because its what the initial feedback was to do. Robert added a lot of
> > >> functionality on top of what was there which is what people were
> > starting
> > >> to ask for. I am in favor of just going off of his patch and moving
> > >> forward. I initially heard post 4.0 so I know I haven't been focused
> on
> > it
> > >> but if theres desire to put it in 4.0 I am +1 on it and would like to
> > see
> > >> just going off of the Robert's latest patch.
> > >>
> > >> Chris
> > >>
> > >> On Thu, Apr 9, 2020 at 6:41 AM Benjamin Lerer <
> > benjamin.lerer@datastax.com
> > >>>
> > >> wrote:
> > >>
> > >>> Thanks for your answer Alex.
> > >>>
> > >>> Some of the things we
> > >>>> have explicitly (as a community) agreed to commit are still in
> > >> progress,
> > >>>> including several client protocol changes. And, to my understanding,
> > if
> > >>>> those are committed, it'll be what community has agreed upon.
> > >>>>
> > >>>
> > >>> If the understanding of the community was that this patch was
> expected
> > to
> > >>> go in 4.0 then it makes sense to commit it there.
> > >>>
> > >>>
> > >>>> If the discussion is about whether or not to include _some_ version
> of
> > >>> the
> > >>>> patch, I think including it makes sense, especially given the patch
> > was
> > >>>> there for a while and was not committed for non-technical reasons.
> If
> > >>> we're
> > >>>> trying to decide _which_ patch to commit, I'd personally focus on
> the
> > >>>> original patch (to foster recognition), get it reviewed, and pick
> any
> > >>>> changes that make it better from the follow-up one (to foster
> > >>>> collaboration).
> > >>>>
> > >>>
> > >>> I am fine going through both patches and figuring out a way to merge
> > them
> > >>> into one if Jon or somebody else is willing to review the output of
> > that
> > >>> merge
> > >>>
> > >>>
> > >>>
> > >>> On Thu, Apr 9, 2020 at 12:45 PM Benedict Elliott Smith <
> > >>> benedict@apache.org>
> > >>> wrote:
> > >>>
> > >>>> +1 all of this
> > >>>>
> > >>>> On 09/04/2020, 10:23, "Oleksandr Petrov" <
> oleksandr.petrov@gmail.com
> > >
> > >>>> wrote:
> > >>>>
> > >>>>> My understanding is that a majority of people ended up in favor
> > >> of
> > >>>> a DESCRIBE approach. Robert made a patch for that approach
> > >> (according
> > >>>> to
> > >>>> his comment it was discussed with Chris beforehand).
> > >>>>
> > >>>> This sounds like just a switch of API (in other words, you use
> the
> > >>> same
> > >>>> string generation, but return it via different means). From the
> > >>>> (little)
> > >>>> time I've spent looking at the patch, I remember that there
> wasn't
> > >>> much
> > >>>> common code between the two (sorry if I'm remembering it wrong).
> > >>>>
> > >>>> If the discussion is about whether or not to include _some_
> version
> > >>> of
> > >>>> the
> > >>>> patch, I think including it makes sense, especially given the
> patch
> > >>> was
> > >>>> there for a while and was not committed for non-technical
> reasons.
> > >> If
> > >>>> we're
> > >>>> trying to decide _which_ patch to commit, I'd personally focus on
> > >> the
> > >>>> original patch (to foster recognition), get it reviewed, and pick
> > >> any
> > >>>> changes that make it better from the follow-up one (to foster
> > >>>> collaboration).
> > >>>>
> > >>>>> Where do we draw the line?
> > >>>>
> > >>>> I would discuss changes on the case-by-case basis. Some of the
> > >> things
> > >>>> we
> > >>>> have explicitly (as a community) agreed to commit are still in
> > >>>> progress,
> > >>>> including several client protocol changes. And, to my
> > >> understanding,
> > >>> if
> > >>>> those are committed, it'll be what community has agreed upon. All
> > >>>> further
> > >>>> changes that weren't discussed yet - we can talk over. If it's
> > >>>> something as
> > >>>> trivial as server-side describe that doesn't risk stability but
> > >> adds
> > >>> a
> > >>>> lot
> > >>>> of value, it may make sense to include. But I woudln't attempt to
> > >>> come
> > >>>> up
> > >>>> with a general rule for what we may or may not consider for now.
> > >>>>
> > >>>>
> > >>>> On Mon, Apr 6, 2020 at 3:21 PM Benjamin Lerer <
> > >>>> benjamin.lerer@datastax.com>
> > >>>> wrote:
> > >>>>
> > >>>>> We have already discussed it for several days and I believe that
> > >>> all
> > >>>> the
> > >>>>> points have been brought to the table.
> > >>>>>
> > >>>>> I took the time to read CASSANDRA-14825 this morning to
> > >> understand
> > >>>> the full
> > >>>>> story.
> > >>>>> All the discussion has been about using Virtual Tables versus
> > >> using
> > >>>>> DESCRIBE.
> > >>>>> My understanding is that a majority of people ended up in favor
> > >> of
> > >>> a
> > >>>>> DESCRIBE approach (skipping the details on purpose here).
> > >>>>> Robert made a patch for that approach (according to his comment
> > >> it
> > >>>> was
> > >>>>> discussed with Chris beforehand).
> > >>>>>
> > >>>>> The question here is should: we agree to put it in 4.0 even if
> > >> the
> > >>>> version
> > >>>>> is frozen for improvements.
> > >>>>>
> > >>>>> My main reason against it is that if we broke the freeze for
> > >> every
> > >>>> ticket
> > >>>>> we believe might be useful we will end up delaying 4.0 a lot.
> > >>>>> Are there not other tickets that are more valuable than
> > >>>> CASSANDRA-14825,
> > >>>>> that are not included in 4.0?
> > >>>>> Where do we draw the line?
> > >>>>>
> > >>>>> I believe that if we were able to answer that question it would
> > >>>> suddenly
> > >>>>> become much easier to agree on which tickets we put in 4.0.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> On Sun, Apr 5, 2020 at 1:25 AM Benedict Elliott Smith <
> > >>>> benedict@apache.org
> > >>>>>>
> > >>>>> wrote:
> > >>>>>
> > >>>>>> There it is. I knew it would show up eventually.
> > >>>>>>
> > >>>>>> On 04/04/2020, 06:26, "benedict@apache.org" <
> > >>>> public@belliottsmith.com>
> > >>>>>> wrote:
> > >>>>>>
> > >>>>>>> scope creep.
> > >>>>>>
> > >>>>>> I think it is unfair to label this scope creep; it would
> > >> have
> > >>>> to be
> > >>>>>> newly considered for 4.0 for it to fall under that umbrella.
> > >>>>>>
> > >>>>>> I don't personally mind if it lands, but this was discussed
> > >>> at
> > >>>> length
> > >>>>>> on multiple occasions over the past year, and only stalled
> > >>> because
> > >>>> of a
> > >>>>>> combination of lack of etiquette, and a lack of leadership from
> > >>>> e.g. PMC
> > >>>>> in
> > >>>>>> resolving various political questions over the course of
> > >> events.
> > >>>>>>
> > >>>>>> I also struggle to see how this would invalidate testing in
> > >>> any
> > >>>>>> significant way? It doesn't modify any existing behaviour.
> > >>>>>>
> > >>>>>> ________________________________
> > >>>>>> From: Joshua McKenzie <jm...@apache.org>
> > >>>>>> Sent: 01 April 2020 19:24
> > >>>>>> To: dev@cassandra.apache.org <de...@cassandra.apache.org>
> > >>>>>> Subject: Re: server side describe
> > >>>>>>
> > >>>>>> This looks like a feature that'd potentially invalidate
> > >> some
> > >>>> testing
> > >>>>>> that's
> > >>>>>> been done and we've been feature frozen for over a year
> > >> and a
> > >>>> half.
> > >>>>>> Also:
> > >>>>>> scope creep.
> > >>>>>>
> > >>>>>> My PoV is we hold off. If we get into a cadence of more
> > >>>> frequent
> > >>>>>> releases
> > >>>>>> we'll have it soon enough.
> > >>>>>>
> > >>>>>> On Wed, Apr 1, 2020 at 3:03 PM <e....@gmail.com>
> > >>> wrote:
> > >>>>>>
> > >>>>>>> Hi,
> > >>>>>>> Normally I ping the person on the ticket or in Slack to
> > >> ask
> > >>>> him/her
> > >>>>>> for
> > >>>>>>> status update and whether I can help. Then probably
> > >> he/she
> > >>>> gives
> > >>>>> me a
> > >>>>>>> direction.
> > >>>>>>> If I can’t find the person anymore, I just use my best
> > >>>> judgement
> > >>>>> and
> > >>>>>>> coordinate with people who might know better than me.
> > >>>>>>> For now this strategy worked for me personally.
> > >>>>>>> Hope this helps
> > >>>>>>> Ekaterina
> > >>>>>>>
> > >>>>>>> Sent from my iPhone
> > >>>>>>>
> > >>>>>>>> On 1 Apr 2020, at 14:27, Jon Haddad <jon@jonhaddad.com
> > >>>
> > >>>> wrote:
> > >>>>>>>>
> > >>>>>>>> Hey folks,
> > >>>>>>>>
> > >>>>>>>> I was looking through our open JIRAs and realized we
> > >>> hadn't
> > >>>>> merged
> > >>>>>> in
> > >>>>>>>> server side describe calls yet. The ticket died off a
> > >>>> ways ago,
> > >>>>>> and I
> > >>>>>>>> pinged Chris about it yesterday. He's got a lot of his
> > >>>> plate and
> > >>>>>> won't
> > >>>>>>> be
> > >>>>>>>> able to work on it anytime soon. I still think we
> > >> should
> > >>>> include
> > >>>>>> this in
> > >>>>>>>> 4.0.
> > >>>>>>>>
> > >>>>>>>> From a technical standpoint, It doesn't say much on the
> > >>>> ticket
> > >>>>>> after
> > >>>>>>> Robert
> > >>>>>>>> tossed an alternative patch out there. I don't mind
> > >>>> reviewing
> > >>>>> and
> > >>>>>>> merging
> > >>>>>>>> either of them, it sounded like both are pretty close
> > >> to
> > >>>> done and
> > >>>>>> I think
> > >>>>>>>> from the perspective of updating drivers for 4.0 this
> > >>> will
> > >>>> save
> > >>>>>> quite a
> > >>>>>>> bit
> > >>>>>>>> of time since driver maintainers won't have to add new
> > >>> CQL
> > >>>>>> generation for
> > >>>>>>>> the various new options that have recently appeared.
> > >>>>>>>>
> > >>>>>>>> Questions:
> > >>>>>>>>
> > >>>>>>>> * Does anyone have an objection to getting this into
> > >> 4.0?
> > >>>> The
> > >>>>>> patches
> > >>>>>>>> aren't too huge, I think they're low risk, and also
> > >>> fairly
> > >>>> high
> > >>>>>> reward.
> > >>>>>>>> * I don't have an opinion (yet) on Robert's patch vs
> > >>>> Chris's,
> > >>>>> with
> > >>>>>> regard
> > >>>>>>>> to which is preferable.
> > >>>>>>>> * Since soon after Robert put up his PR he hasn't been
> > >>>> around, at
> > >>>>>> least
> > >>>>>>> as
> > >>>>>>>> far as I've seen. How have we dealt with abandoned
> > >>> patches
> > >>>>>> before? If
> > >>>>>>>> we're going to add this in the patch will need some
> > >>>> cleanup. Is
> > >>>>> it
> > >>>>>>>> reasonable to continue someone else's work when they've
> > >>>>>> disappeared?
> > >>>>>>>>
> > >>>>>>>> Jon
> > >>>>>>>
> > >>>>>>>
> > >>>>>
> > >>> ---------------------------------------------------------------------
> > >>>>>>> To unsubscribe, e-mail:
> > >>> dev-unsubscribe@cassandra.apache.org
> > >>>>>>> For additional commands, e-mail:
> > >>>> dev-help@cassandra.apache.org
> > >>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>
> ---------------------------------------------------------------------
> > >>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > >>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>>
> > >>>> --
> > >>>> alex p
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> ---------------------------------------------------------------------
> > >>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > >>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> > >>>>
> > >>>>
> > >>>
> > >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
> >
>
Re: server side describe
Posted by sankalp kohli <ko...@gmail.com>.
What are the next steps? Do we hold a vote as I see few initial emails
which dont seem to agree and have not replied based on future discussions.
On Fri, Apr 10, 2020 at 12:50 PM Dinesh Joshi <dj...@apache.org> wrote:
> +1 let's keep moving forward.
>
> Dinesh
>
> > On Apr 9, 2020, at 4:07 PM, Nate McCall <zz...@gmail.com> wrote:
> >
> > Ok cool. It sounds like we are moving this towards a consensus? (at least
> > agreeing to disagree and moving forward).
> >
> > I very much the different inputs on this thread - thanks for a largely
> > healthy discussion folks.
> >
> > On Fri, Apr 10, 2020 at 6:03 AM Chris Lohfink <cl...@gmail.com>
> wrote:
> >
> >> I'd be in favor of going with the newer DESCRIBE option. The original
> patch
> >> was mostly focused on just getting the CQL correct and used virtual
> tables
> >> because its what the initial feedback was to do. Robert added a lot of
> >> functionality on top of what was there which is what people were
> starting
> >> to ask for. I am in favor of just going off of his patch and moving
> >> forward. I initially heard post 4.0 so I know I haven't been focused on
> it
> >> but if theres desire to put it in 4.0 I am +1 on it and would like to
> see
> >> just going off of the Robert's latest patch.
> >>
> >> Chris
> >>
> >> On Thu, Apr 9, 2020 at 6:41 AM Benjamin Lerer <
> benjamin.lerer@datastax.com
> >>>
> >> wrote:
> >>
> >>> Thanks for your answer Alex.
> >>>
> >>> Some of the things we
> >>>> have explicitly (as a community) agreed to commit are still in
> >> progress,
> >>>> including several client protocol changes. And, to my understanding,
> if
> >>>> those are committed, it'll be what community has agreed upon.
> >>>>
> >>>
> >>> If the understanding of the community was that this patch was expected
> to
> >>> go in 4.0 then it makes sense to commit it there.
> >>>
> >>>
> >>>> If the discussion is about whether or not to include _some_ version of
> >>> the
> >>>> patch, I think including it makes sense, especially given the patch
> was
> >>>> there for a while and was not committed for non-technical reasons. If
> >>> we're
> >>>> trying to decide _which_ patch to commit, I'd personally focus on the
> >>>> original patch (to foster recognition), get it reviewed, and pick any
> >>>> changes that make it better from the follow-up one (to foster
> >>>> collaboration).
> >>>>
> >>>
> >>> I am fine going through both patches and figuring out a way to merge
> them
> >>> into one if Jon or somebody else is willing to review the output of
> that
> >>> merge
> >>>
> >>>
> >>>
> >>> On Thu, Apr 9, 2020 at 12:45 PM Benedict Elliott Smith <
> >>> benedict@apache.org>
> >>> wrote:
> >>>
> >>>> +1 all of this
> >>>>
> >>>> On 09/04/2020, 10:23, "Oleksandr Petrov" <oleksandr.petrov@gmail.com
> >
> >>>> wrote:
> >>>>
> >>>>> My understanding is that a majority of people ended up in favor
> >> of
> >>>> a DESCRIBE approach. Robert made a patch for that approach
> >> (according
> >>>> to
> >>>> his comment it was discussed with Chris beforehand).
> >>>>
> >>>> This sounds like just a switch of API (in other words, you use the
> >>> same
> >>>> string generation, but return it via different means). From the
> >>>> (little)
> >>>> time I've spent looking at the patch, I remember that there wasn't
> >>> much
> >>>> common code between the two (sorry if I'm remembering it wrong).
> >>>>
> >>>> If the discussion is about whether or not to include _some_ version
> >>> of
> >>>> the
> >>>> patch, I think including it makes sense, especially given the patch
> >>> was
> >>>> there for a while and was not committed for non-technical reasons.
> >> If
> >>>> we're
> >>>> trying to decide _which_ patch to commit, I'd personally focus on
> >> the
> >>>> original patch (to foster recognition), get it reviewed, and pick
> >> any
> >>>> changes that make it better from the follow-up one (to foster
> >>>> collaboration).
> >>>>
> >>>>> Where do we draw the line?
> >>>>
> >>>> I would discuss changes on the case-by-case basis. Some of the
> >> things
> >>>> we
> >>>> have explicitly (as a community) agreed to commit are still in
> >>>> progress,
> >>>> including several client protocol changes. And, to my
> >> understanding,
> >>> if
> >>>> those are committed, it'll be what community has agreed upon. All
> >>>> further
> >>>> changes that weren't discussed yet - we can talk over. If it's
> >>>> something as
> >>>> trivial as server-side describe that doesn't risk stability but
> >> adds
> >>> a
> >>>> lot
> >>>> of value, it may make sense to include. But I woudln't attempt to
> >>> come
> >>>> up
> >>>> with a general rule for what we may or may not consider for now.
> >>>>
> >>>>
> >>>> On Mon, Apr 6, 2020 at 3:21 PM Benjamin Lerer <
> >>>> benjamin.lerer@datastax.com>
> >>>> wrote:
> >>>>
> >>>>> We have already discussed it for several days and I believe that
> >>> all
> >>>> the
> >>>>> points have been brought to the table.
> >>>>>
> >>>>> I took the time to read CASSANDRA-14825 this morning to
> >> understand
> >>>> the full
> >>>>> story.
> >>>>> All the discussion has been about using Virtual Tables versus
> >> using
> >>>>> DESCRIBE.
> >>>>> My understanding is that a majority of people ended up in favor
> >> of
> >>> a
> >>>>> DESCRIBE approach (skipping the details on purpose here).
> >>>>> Robert made a patch for that approach (according to his comment
> >> it
> >>>> was
> >>>>> discussed with Chris beforehand).
> >>>>>
> >>>>> The question here is should: we agree to put it in 4.0 even if
> >> the
> >>>> version
> >>>>> is frozen for improvements.
> >>>>>
> >>>>> My main reason against it is that if we broke the freeze for
> >> every
> >>>> ticket
> >>>>> we believe might be useful we will end up delaying 4.0 a lot.
> >>>>> Are there not other tickets that are more valuable than
> >>>> CASSANDRA-14825,
> >>>>> that are not included in 4.0?
> >>>>> Where do we draw the line?
> >>>>>
> >>>>> I believe that if we were able to answer that question it would
> >>>> suddenly
> >>>>> become much easier to agree on which tickets we put in 4.0.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Sun, Apr 5, 2020 at 1:25 AM Benedict Elliott Smith <
> >>>> benedict@apache.org
> >>>>>>
> >>>>> wrote:
> >>>>>
> >>>>>> There it is. I knew it would show up eventually.
> >>>>>>
> >>>>>> On 04/04/2020, 06:26, "benedict@apache.org" <
> >>>> public@belliottsmith.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> scope creep.
> >>>>>>
> >>>>>> I think it is unfair to label this scope creep; it would
> >> have
> >>>> to be
> >>>>>> newly considered for 4.0 for it to fall under that umbrella.
> >>>>>>
> >>>>>> I don't personally mind if it lands, but this was discussed
> >>> at
> >>>> length
> >>>>>> on multiple occasions over the past year, and only stalled
> >>> because
> >>>> of a
> >>>>>> combination of lack of etiquette, and a lack of leadership from
> >>>> e.g. PMC
> >>>>> in
> >>>>>> resolving various political questions over the course of
> >> events.
> >>>>>>
> >>>>>> I also struggle to see how this would invalidate testing in
> >>> any
> >>>>>> significant way? It doesn't modify any existing behaviour.
> >>>>>>
> >>>>>> ________________________________
> >>>>>> From: Joshua McKenzie <jm...@apache.org>
> >>>>>> Sent: 01 April 2020 19:24
> >>>>>> To: dev@cassandra.apache.org <de...@cassandra.apache.org>
> >>>>>> Subject: Re: server side describe
> >>>>>>
> >>>>>> This looks like a feature that'd potentially invalidate
> >> some
> >>>> testing
> >>>>>> that's
> >>>>>> been done and we've been feature frozen for over a year
> >> and a
> >>>> half.
> >>>>>> Also:
> >>>>>> scope creep.
> >>>>>>
> >>>>>> My PoV is we hold off. If we get into a cadence of more
> >>>> frequent
> >>>>>> releases
> >>>>>> we'll have it soon enough.
> >>>>>>
> >>>>>> On Wed, Apr 1, 2020 at 3:03 PM <e....@gmail.com>
> >>> wrote:
> >>>>>>
> >>>>>>> Hi,
> >>>>>>> Normally I ping the person on the ticket or in Slack to
> >> ask
> >>>> him/her
> >>>>>> for
> >>>>>>> status update and whether I can help. Then probably
> >> he/she
> >>>> gives
> >>>>> me a
> >>>>>>> direction.
> >>>>>>> If I can’t find the person anymore, I just use my best
> >>>> judgement
> >>>>> and
> >>>>>>> coordinate with people who might know better than me.
> >>>>>>> For now this strategy worked for me personally.
> >>>>>>> Hope this helps
> >>>>>>> Ekaterina
> >>>>>>>
> >>>>>>> Sent from my iPhone
> >>>>>>>
> >>>>>>>> On 1 Apr 2020, at 14:27, Jon Haddad <jon@jonhaddad.com
> >>>
> >>>> wrote:
> >>>>>>>>
> >>>>>>>> Hey folks,
> >>>>>>>>
> >>>>>>>> I was looking through our open JIRAs and realized we
> >>> hadn't
> >>>>> merged
> >>>>>> in
> >>>>>>>> server side describe calls yet. The ticket died off a
> >>>> ways ago,
> >>>>>> and I
> >>>>>>>> pinged Chris about it yesterday. He's got a lot of his
> >>>> plate and
> >>>>>> won't
> >>>>>>> be
> >>>>>>>> able to work on it anytime soon. I still think we
> >> should
> >>>> include
> >>>>>> this in
> >>>>>>>> 4.0.
> >>>>>>>>
> >>>>>>>> From a technical standpoint, It doesn't say much on the
> >>>> ticket
> >>>>>> after
> >>>>>>> Robert
> >>>>>>>> tossed an alternative patch out there. I don't mind
> >>>> reviewing
> >>>>> and
> >>>>>>> merging
> >>>>>>>> either of them, it sounded like both are pretty close
> >> to
> >>>> done and
> >>>>>> I think
> >>>>>>>> from the perspective of updating drivers for 4.0 this
> >>> will
> >>>> save
> >>>>>> quite a
> >>>>>>> bit
> >>>>>>>> of time since driver maintainers won't have to add new
> >>> CQL
> >>>>>> generation for
> >>>>>>>> the various new options that have recently appeared.
> >>>>>>>>
> >>>>>>>> Questions:
> >>>>>>>>
> >>>>>>>> * Does anyone have an objection to getting this into
> >> 4.0?
> >>>> The
> >>>>>> patches
> >>>>>>>> aren't too huge, I think they're low risk, and also
> >>> fairly
> >>>> high
> >>>>>> reward.
> >>>>>>>> * I don't have an opinion (yet) on Robert's patch vs
> >>>> Chris's,
> >>>>> with
> >>>>>> regard
> >>>>>>>> to which is preferable.
> >>>>>>>> * Since soon after Robert put up his PR he hasn't been
> >>>> around, at
> >>>>>> least
> >>>>>>> as
> >>>>>>>> far as I've seen. How have we dealt with abandoned
> >>> patches
> >>>>>> before? If
> >>>>>>>> we're going to add this in the patch will need some
> >>>> cleanup. Is
> >>>>> it
> >>>>>>>> reasonable to continue someone else's work when they've
> >>>>>> disappeared?
> >>>>>>>>
> >>>>>>>> Jon
> >>>>>>>
> >>>>>>>
> >>>>>
> >>> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail:
> >>> dev-unsubscribe@cassandra.apache.org
> >>>>>>> For additional commands, e-mail:
> >>>> dev-help@cassandra.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> alex p
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>>
> >>>>
> >>>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
Re: server side describe
Posted by Dinesh Joshi <dj...@apache.org>.
+1 let's keep moving forward.
Dinesh
> On Apr 9, 2020, at 4:07 PM, Nate McCall <zz...@gmail.com> wrote:
>
> Ok cool. It sounds like we are moving this towards a consensus? (at least
> agreeing to disagree and moving forward).
>
> I very much the different inputs on this thread - thanks for a largely
> healthy discussion folks.
>
> On Fri, Apr 10, 2020 at 6:03 AM Chris Lohfink <cl...@gmail.com> wrote:
>
>> I'd be in favor of going with the newer DESCRIBE option. The original patch
>> was mostly focused on just getting the CQL correct and used virtual tables
>> because its what the initial feedback was to do. Robert added a lot of
>> functionality on top of what was there which is what people were starting
>> to ask for. I am in favor of just going off of his patch and moving
>> forward. I initially heard post 4.0 so I know I haven't been focused on it
>> but if theres desire to put it in 4.0 I am +1 on it and would like to see
>> just going off of the Robert's latest patch.
>>
>> Chris
>>
>> On Thu, Apr 9, 2020 at 6:41 AM Benjamin Lerer <benjamin.lerer@datastax.com
>>>
>> wrote:
>>
>>> Thanks for your answer Alex.
>>>
>>> Some of the things we
>>>> have explicitly (as a community) agreed to commit are still in
>> progress,
>>>> including several client protocol changes. And, to my understanding, if
>>>> those are committed, it'll be what community has agreed upon.
>>>>
>>>
>>> If the understanding of the community was that this patch was expected to
>>> go in 4.0 then it makes sense to commit it there.
>>>
>>>
>>>> If the discussion is about whether or not to include _some_ version of
>>> the
>>>> patch, I think including it makes sense, especially given the patch was
>>>> there for a while and was not committed for non-technical reasons. If
>>> we're
>>>> trying to decide _which_ patch to commit, I'd personally focus on the
>>>> original patch (to foster recognition), get it reviewed, and pick any
>>>> changes that make it better from the follow-up one (to foster
>>>> collaboration).
>>>>
>>>
>>> I am fine going through both patches and figuring out a way to merge them
>>> into one if Jon or somebody else is willing to review the output of that
>>> merge
>>>
>>>
>>>
>>> On Thu, Apr 9, 2020 at 12:45 PM Benedict Elliott Smith <
>>> benedict@apache.org>
>>> wrote:
>>>
>>>> +1 all of this
>>>>
>>>> On 09/04/2020, 10:23, "Oleksandr Petrov" <ol...@gmail.com>
>>>> wrote:
>>>>
>>>>> My understanding is that a majority of people ended up in favor
>> of
>>>> a DESCRIBE approach. Robert made a patch for that approach
>> (according
>>>> to
>>>> his comment it was discussed with Chris beforehand).
>>>>
>>>> This sounds like just a switch of API (in other words, you use the
>>> same
>>>> string generation, but return it via different means). From the
>>>> (little)
>>>> time I've spent looking at the patch, I remember that there wasn't
>>> much
>>>> common code between the two (sorry if I'm remembering it wrong).
>>>>
>>>> If the discussion is about whether or not to include _some_ version
>>> of
>>>> the
>>>> patch, I think including it makes sense, especially given the patch
>>> was
>>>> there for a while and was not committed for non-technical reasons.
>> If
>>>> we're
>>>> trying to decide _which_ patch to commit, I'd personally focus on
>> the
>>>> original patch (to foster recognition), get it reviewed, and pick
>> any
>>>> changes that make it better from the follow-up one (to foster
>>>> collaboration).
>>>>
>>>>> Where do we draw the line?
>>>>
>>>> I would discuss changes on the case-by-case basis. Some of the
>> things
>>>> we
>>>> have explicitly (as a community) agreed to commit are still in
>>>> progress,
>>>> including several client protocol changes. And, to my
>> understanding,
>>> if
>>>> those are committed, it'll be what community has agreed upon. All
>>>> further
>>>> changes that weren't discussed yet - we can talk over. If it's
>>>> something as
>>>> trivial as server-side describe that doesn't risk stability but
>> adds
>>> a
>>>> lot
>>>> of value, it may make sense to include. But I woudln't attempt to
>>> come
>>>> up
>>>> with a general rule for what we may or may not consider for now.
>>>>
>>>>
>>>> On Mon, Apr 6, 2020 at 3:21 PM Benjamin Lerer <
>>>> benjamin.lerer@datastax.com>
>>>> wrote:
>>>>
>>>>> We have already discussed it for several days and I believe that
>>> all
>>>> the
>>>>> points have been brought to the table.
>>>>>
>>>>> I took the time to read CASSANDRA-14825 this morning to
>> understand
>>>> the full
>>>>> story.
>>>>> All the discussion has been about using Virtual Tables versus
>> using
>>>>> DESCRIBE.
>>>>> My understanding is that a majority of people ended up in favor
>> of
>>> a
>>>>> DESCRIBE approach (skipping the details on purpose here).
>>>>> Robert made a patch for that approach (according to his comment
>> it
>>>> was
>>>>> discussed with Chris beforehand).
>>>>>
>>>>> The question here is should: we agree to put it in 4.0 even if
>> the
>>>> version
>>>>> is frozen for improvements.
>>>>>
>>>>> My main reason against it is that if we broke the freeze for
>> every
>>>> ticket
>>>>> we believe might be useful we will end up delaying 4.0 a lot.
>>>>> Are there not other tickets that are more valuable than
>>>> CASSANDRA-14825,
>>>>> that are not included in 4.0?
>>>>> Where do we draw the line?
>>>>>
>>>>> I believe that if we were able to answer that question it would
>>>> suddenly
>>>>> become much easier to agree on which tickets we put in 4.0.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Sun, Apr 5, 2020 at 1:25 AM Benedict Elliott Smith <
>>>> benedict@apache.org
>>>>>>
>>>>> wrote:
>>>>>
>>>>>> There it is. I knew it would show up eventually.
>>>>>>
>>>>>> On 04/04/2020, 06:26, "benedict@apache.org" <
>>>> public@belliottsmith.com>
>>>>>> wrote:
>>>>>>
>>>>>>> scope creep.
>>>>>>
>>>>>> I think it is unfair to label this scope creep; it would
>> have
>>>> to be
>>>>>> newly considered for 4.0 for it to fall under that umbrella.
>>>>>>
>>>>>> I don't personally mind if it lands, but this was discussed
>>> at
>>>> length
>>>>>> on multiple occasions over the past year, and only stalled
>>> because
>>>> of a
>>>>>> combination of lack of etiquette, and a lack of leadership from
>>>> e.g. PMC
>>>>> in
>>>>>> resolving various political questions over the course of
>> events.
>>>>>>
>>>>>> I also struggle to see how this would invalidate testing in
>>> any
>>>>>> significant way? It doesn't modify any existing behaviour.
>>>>>>
>>>>>> ________________________________
>>>>>> From: Joshua McKenzie <jm...@apache.org>
>>>>>> Sent: 01 April 2020 19:24
>>>>>> To: dev@cassandra.apache.org <de...@cassandra.apache.org>
>>>>>> Subject: Re: server side describe
>>>>>>
>>>>>> This looks like a feature that'd potentially invalidate
>> some
>>>> testing
>>>>>> that's
>>>>>> been done and we've been feature frozen for over a year
>> and a
>>>> half.
>>>>>> Also:
>>>>>> scope creep.
>>>>>>
>>>>>> My PoV is we hold off. If we get into a cadence of more
>>>> frequent
>>>>>> releases
>>>>>> we'll have it soon enough.
>>>>>>
>>>>>> On Wed, Apr 1, 2020 at 3:03 PM <e....@gmail.com>
>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>> Normally I ping the person on the ticket or in Slack to
>> ask
>>>> him/her
>>>>>> for
>>>>>>> status update and whether I can help. Then probably
>> he/she
>>>> gives
>>>>> me a
>>>>>>> direction.
>>>>>>> If I can’t find the person anymore, I just use my best
>>>> judgement
>>>>> and
>>>>>>> coordinate with people who might know better than me.
>>>>>>> For now this strategy worked for me personally.
>>>>>>> Hope this helps
>>>>>>> Ekaterina
>>>>>>>
>>>>>>> Sent from my iPhone
>>>>>>>
>>>>>>>> On 1 Apr 2020, at 14:27, Jon Haddad <jon@jonhaddad.com
>>>
>>>> wrote:
>>>>>>>>
>>>>>>>> Hey folks,
>>>>>>>>
>>>>>>>> I was looking through our open JIRAs and realized we
>>> hadn't
>>>>> merged
>>>>>> in
>>>>>>>> server side describe calls yet. The ticket died off a
>>>> ways ago,
>>>>>> and I
>>>>>>>> pinged Chris about it yesterday. He's got a lot of his
>>>> plate and
>>>>>> won't
>>>>>>> be
>>>>>>>> able to work on it anytime soon. I still think we
>> should
>>>> include
>>>>>> this in
>>>>>>>> 4.0.
>>>>>>>>
>>>>>>>> From a technical standpoint, It doesn't say much on the
>>>> ticket
>>>>>> after
>>>>>>> Robert
>>>>>>>> tossed an alternative patch out there. I don't mind
>>>> reviewing
>>>>> and
>>>>>>> merging
>>>>>>>> either of them, it sounded like both are pretty close
>> to
>>>> done and
>>>>>> I think
>>>>>>>> from the perspective of updating drivers for 4.0 this
>>> will
>>>> save
>>>>>> quite a
>>>>>>> bit
>>>>>>>> of time since driver maintainers won't have to add new
>>> CQL
>>>>>> generation for
>>>>>>>> the various new options that have recently appeared.
>>>>>>>>
>>>>>>>> Questions:
>>>>>>>>
>>>>>>>> * Does anyone have an objection to getting this into
>> 4.0?
>>>> The
>>>>>> patches
>>>>>>>> aren't too huge, I think they're low risk, and also
>>> fairly
>>>> high
>>>>>> reward.
>>>>>>>> * I don't have an opinion (yet) on Robert's patch vs
>>>> Chris's,
>>>>> with
>>>>>> regard
>>>>>>>> to which is preferable.
>>>>>>>> * Since soon after Robert put up his PR he hasn't been
>>>> around, at
>>>>>> least
>>>>>>> as
>>>>>>>> far as I've seen. How have we dealt with abandoned
>>> patches
>>>>>> before? If
>>>>>>>> we're going to add this in the patch will need some
>>>> cleanup. Is
>>>>> it
>>>>>>>> reasonable to continue someone else's work when they've
>>>>>> disappeared?
>>>>>>>>
>>>>>>>> Jon
>>>>>>>
>>>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail:
>>> dev-unsubscribe@cassandra.apache.org
>>>>>>> For additional commands, e-mail:
>>>> dev-help@cassandra.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> alex p
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>
>>>>
>>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: server side describe
Posted by Nate McCall <zz...@gmail.com>.
Ok cool. It sounds like we are moving this towards a consensus? (at least
agreeing to disagree and moving forward).
I very much the different inputs on this thread - thanks for a largely
healthy discussion folks.
On Fri, Apr 10, 2020 at 6:03 AM Chris Lohfink <cl...@gmail.com> wrote:
> I'd be in favor of going with the newer DESCRIBE option. The original patch
> was mostly focused on just getting the CQL correct and used virtual tables
> because its what the initial feedback was to do. Robert added a lot of
> functionality on top of what was there which is what people were starting
> to ask for. I am in favor of just going off of his patch and moving
> forward. I initially heard post 4.0 so I know I haven't been focused on it
> but if theres desire to put it in 4.0 I am +1 on it and would like to see
> just going off of the Robert's latest patch.
>
> Chris
>
> On Thu, Apr 9, 2020 at 6:41 AM Benjamin Lerer <benjamin.lerer@datastax.com
> >
> wrote:
>
> > Thanks for your answer Alex.
> >
> > Some of the things we
> > > have explicitly (as a community) agreed to commit are still in
> progress,
> > > including several client protocol changes. And, to my understanding, if
> > > those are committed, it'll be what community has agreed upon.
> > >
> >
> > If the understanding of the community was that this patch was expected to
> > go in 4.0 then it makes sense to commit it there.
> >
> >
> > > If the discussion is about whether or not to include _some_ version of
> > the
> > > patch, I think including it makes sense, especially given the patch was
> > > there for a while and was not committed for non-technical reasons. If
> > we're
> > > trying to decide _which_ patch to commit, I'd personally focus on the
> > > original patch (to foster recognition), get it reviewed, and pick any
> > > changes that make it better from the follow-up one (to foster
> > > collaboration).
> > >
> >
> > I am fine going through both patches and figuring out a way to merge them
> > into one if Jon or somebody else is willing to review the output of that
> > merge
> >
> >
> >
> > On Thu, Apr 9, 2020 at 12:45 PM Benedict Elliott Smith <
> > benedict@apache.org>
> > wrote:
> >
> > > +1 all of this
> > >
> > > On 09/04/2020, 10:23, "Oleksandr Petrov" <ol...@gmail.com>
> > > wrote:
> > >
> > > > My understanding is that a majority of people ended up in favor
> of
> > > a DESCRIBE approach. Robert made a patch for that approach
> (according
> > > to
> > > his comment it was discussed with Chris beforehand).
> > >
> > > This sounds like just a switch of API (in other words, you use the
> > same
> > > string generation, but return it via different means). From the
> > > (little)
> > > time I've spent looking at the patch, I remember that there wasn't
> > much
> > > common code between the two (sorry if I'm remembering it wrong).
> > >
> > > If the discussion is about whether or not to include _some_ version
> > of
> > > the
> > > patch, I think including it makes sense, especially given the patch
> > was
> > > there for a while and was not committed for non-technical reasons.
> If
> > > we're
> > > trying to decide _which_ patch to commit, I'd personally focus on
> the
> > > original patch (to foster recognition), get it reviewed, and pick
> any
> > > changes that make it better from the follow-up one (to foster
> > > collaboration).
> > >
> > > > Where do we draw the line?
> > >
> > > I would discuss changes on the case-by-case basis. Some of the
> things
> > > we
> > > have explicitly (as a community) agreed to commit are still in
> > > progress,
> > > including several client protocol changes. And, to my
> understanding,
> > if
> > > those are committed, it'll be what community has agreed upon. All
> > > further
> > > changes that weren't discussed yet - we can talk over. If it's
> > > something as
> > > trivial as server-side describe that doesn't risk stability but
> adds
> > a
> > > lot
> > > of value, it may make sense to include. But I woudln't attempt to
> > come
> > > up
> > > with a general rule for what we may or may not consider for now.
> > >
> > >
> > > On Mon, Apr 6, 2020 at 3:21 PM Benjamin Lerer <
> > > benjamin.lerer@datastax.com>
> > > wrote:
> > >
> > > > We have already discussed it for several days and I believe that
> > all
> > > the
> > > > points have been brought to the table.
> > > >
> > > > I took the time to read CASSANDRA-14825 this morning to
> understand
> > > the full
> > > > story.
> > > > All the discussion has been about using Virtual Tables versus
> using
> > > > DESCRIBE.
> > > > My understanding is that a majority of people ended up in favor
> of
> > a
> > > > DESCRIBE approach (skipping the details on purpose here).
> > > > Robert made a patch for that approach (according to his comment
> it
> > > was
> > > > discussed with Chris beforehand).
> > > >
> > > > The question here is should: we agree to put it in 4.0 even if
> the
> > > version
> > > > is frozen for improvements.
> > > >
> > > > My main reason against it is that if we broke the freeze for
> every
> > > ticket
> > > > we believe might be useful we will end up delaying 4.0 a lot.
> > > > Are there not other tickets that are more valuable than
> > > CASSANDRA-14825,
> > > > that are not included in 4.0?
> > > > Where do we draw the line?
> > > >
> > > > I believe that if we were able to answer that question it would
> > > suddenly
> > > > become much easier to agree on which tickets we put in 4.0.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Sun, Apr 5, 2020 at 1:25 AM Benedict Elliott Smith <
> > > benedict@apache.org
> > > > >
> > > > wrote:
> > > >
> > > > > There it is. I knew it would show up eventually.
> > > > >
> > > > > On 04/04/2020, 06:26, "benedict@apache.org" <
> > > public@belliottsmith.com>
> > > > > wrote:
> > > > >
> > > > > > scope creep.
> > > > >
> > > > > I think it is unfair to label this scope creep; it would
> have
> > > to be
> > > > > newly considered for 4.0 for it to fall under that umbrella.
> > > > >
> > > > > I don't personally mind if it lands, but this was discussed
> > at
> > > length
> > > > > on multiple occasions over the past year, and only stalled
> > because
> > > of a
> > > > > combination of lack of etiquette, and a lack of leadership from
> > > e.g. PMC
> > > > in
> > > > > resolving various political questions over the course of
> events.
> > > > >
> > > > > I also struggle to see how this would invalidate testing in
> > any
> > > > > significant way? It doesn't modify any existing behaviour.
> > > > >
> > > > > ________________________________
> > > > > From: Joshua McKenzie <jm...@apache.org>
> > > > > Sent: 01 April 2020 19:24
> > > > > To: dev@cassandra.apache.org <de...@cassandra.apache.org>
> > > > > Subject: Re: server side describe
> > > > >
> > > > > This looks like a feature that'd potentially invalidate
> some
> > > testing
> > > > > that's
> > > > > been done and we've been feature frozen for over a year
> and a
> > > half.
> > > > > Also:
> > > > > scope creep.
> > > > >
> > > > > My PoV is we hold off. If we get into a cadence of more
> > > frequent
> > > > > releases
> > > > > we'll have it soon enough.
> > > > >
> > > > > On Wed, Apr 1, 2020 at 3:03 PM <e....@gmail.com>
> > wrote:
> > > > >
> > > > > > Hi,
> > > > > > Normally I ping the person on the ticket or in Slack to
> ask
> > > him/her
> > > > > for
> > > > > > status update and whether I can help. Then probably
> he/she
> > > gives
> > > > me a
> > > > > > direction.
> > > > > > If I can’t find the person anymore, I just use my best
> > > judgement
> > > > and
> > > > > > coordinate with people who might know better than me.
> > > > > > For now this strategy worked for me personally.
> > > > > > Hope this helps
> > > > > > Ekaterina
> > > > > >
> > > > > > Sent from my iPhone
> > > > > >
> > > > > > > On 1 Apr 2020, at 14:27, Jon Haddad <jon@jonhaddad.com
> >
> > > wrote:
> > > > > > >
> > > > > > > Hey folks,
> > > > > > >
> > > > > > > I was looking through our open JIRAs and realized we
> > hadn't
> > > > merged
> > > > > in
> > > > > > > server side describe calls yet. The ticket died off a
> > > ways ago,
> > > > > and I
> > > > > > > pinged Chris about it yesterday. He's got a lot of his
> > > plate and
> > > > > won't
> > > > > > be
> > > > > > > able to work on it anytime soon. I still think we
> should
> > > include
> > > > > this in
> > > > > > > 4.0.
> > > > > > >
> > > > > > > From a technical standpoint, It doesn't say much on the
> > > ticket
> > > > > after
> > > > > > Robert
> > > > > > > tossed an alternative patch out there. I don't mind
> > > reviewing
> > > > and
> > > > > > merging
> > > > > > > either of them, it sounded like both are pretty close
> to
> > > done and
> > > > > I think
> > > > > > > from the perspective of updating drivers for 4.0 this
> > will
> > > save
> > > > > quite a
> > > > > > bit
> > > > > > > of time since driver maintainers won't have to add new
> > CQL
> > > > > generation for
> > > > > > > the various new options that have recently appeared.
> > > > > > >
> > > > > > > Questions:
> > > > > > >
> > > > > > > * Does anyone have an objection to getting this into
> 4.0?
> > > The
> > > > > patches
> > > > > > > aren't too huge, I think they're low risk, and also
> > fairly
> > > high
> > > > > reward.
> > > > > > > * I don't have an opinion (yet) on Robert's patch vs
> > > Chris's,
> > > > with
> > > > > regard
> > > > > > > to which is preferable.
> > > > > > > * Since soon after Robert put up his PR he hasn't been
> > > around, at
> > > > > least
> > > > > > as
> > > > > > > far as I've seen. How have we dealt with abandoned
> > patches
> > > > > before? If
> > > > > > > we're going to add this in the patch will need some
> > > cleanup. Is
> > > > it
> > > > > > > reasonable to continue someone else's work when they've
> > > > > disappeared?
> > > > > > >
> > > > > > > Jon
> > > > > >
> > > > > >
> > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail:
> > dev-unsubscribe@cassandra.apache.org
> > > > > > For additional commands, e-mail:
> > > dev-help@cassandra.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > > > > For additional commands, e-mail: dev-help@cassandra.apache.org
> > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > alex p
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > > For additional commands, e-mail: dev-help@cassandra.apache.org
> > >
> > >
> >
>
Re: server side describe
Posted by Chris Lohfink <cl...@gmail.com>.
I'd be in favor of going with the newer DESCRIBE option. The original patch
was mostly focused on just getting the CQL correct and used virtual tables
because its what the initial feedback was to do. Robert added a lot of
functionality on top of what was there which is what people were starting
to ask for. I am in favor of just going off of his patch and moving
forward. I initially heard post 4.0 so I know I haven't been focused on it
but if theres desire to put it in 4.0 I am +1 on it and would like to see
just going off of the Robert's latest patch.
Chris
On Thu, Apr 9, 2020 at 6:41 AM Benjamin Lerer <be...@datastax.com>
wrote:
> Thanks for your answer Alex.
>
> Some of the things we
> > have explicitly (as a community) agreed to commit are still in progress,
> > including several client protocol changes. And, to my understanding, if
> > those are committed, it'll be what community has agreed upon.
> >
>
> If the understanding of the community was that this patch was expected to
> go in 4.0 then it makes sense to commit it there.
>
>
> > If the discussion is about whether or not to include _some_ version of
> the
> > patch, I think including it makes sense, especially given the patch was
> > there for a while and was not committed for non-technical reasons. If
> we're
> > trying to decide _which_ patch to commit, I'd personally focus on the
> > original patch (to foster recognition), get it reviewed, and pick any
> > changes that make it better from the follow-up one (to foster
> > collaboration).
> >
>
> I am fine going through both patches and figuring out a way to merge them
> into one if Jon or somebody else is willing to review the output of that
> merge
>
>
>
> On Thu, Apr 9, 2020 at 12:45 PM Benedict Elliott Smith <
> benedict@apache.org>
> wrote:
>
> > +1 all of this
> >
> > On 09/04/2020, 10:23, "Oleksandr Petrov" <ol...@gmail.com>
> > wrote:
> >
> > > My understanding is that a majority of people ended up in favor of
> > a DESCRIBE approach. Robert made a patch for that approach (according
> > to
> > his comment it was discussed with Chris beforehand).
> >
> > This sounds like just a switch of API (in other words, you use the
> same
> > string generation, but return it via different means). From the
> > (little)
> > time I've spent looking at the patch, I remember that there wasn't
> much
> > common code between the two (sorry if I'm remembering it wrong).
> >
> > If the discussion is about whether or not to include _some_ version
> of
> > the
> > patch, I think including it makes sense, especially given the patch
> was
> > there for a while and was not committed for non-technical reasons. If
> > we're
> > trying to decide _which_ patch to commit, I'd personally focus on the
> > original patch (to foster recognition), get it reviewed, and pick any
> > changes that make it better from the follow-up one (to foster
> > collaboration).
> >
> > > Where do we draw the line?
> >
> > I would discuss changes on the case-by-case basis. Some of the things
> > we
> > have explicitly (as a community) agreed to commit are still in
> > progress,
> > including several client protocol changes. And, to my understanding,
> if
> > those are committed, it'll be what community has agreed upon. All
> > further
> > changes that weren't discussed yet - we can talk over. If it's
> > something as
> > trivial as server-side describe that doesn't risk stability but adds
> a
> > lot
> > of value, it may make sense to include. But I woudln't attempt to
> come
> > up
> > with a general rule for what we may or may not consider for now.
> >
> >
> > On Mon, Apr 6, 2020 at 3:21 PM Benjamin Lerer <
> > benjamin.lerer@datastax.com>
> > wrote:
> >
> > > We have already discussed it for several days and I believe that
> all
> > the
> > > points have been brought to the table.
> > >
> > > I took the time to read CASSANDRA-14825 this morning to understand
> > the full
> > > story.
> > > All the discussion has been about using Virtual Tables versus using
> > > DESCRIBE.
> > > My understanding is that a majority of people ended up in favor of
> a
> > > DESCRIBE approach (skipping the details on purpose here).
> > > Robert made a patch for that approach (according to his comment it
> > was
> > > discussed with Chris beforehand).
> > >
> > > The question here is should: we agree to put it in 4.0 even if the
> > version
> > > is frozen for improvements.
> > >
> > > My main reason against it is that if we broke the freeze for every
> > ticket
> > > we believe might be useful we will end up delaying 4.0 a lot.
> > > Are there not other tickets that are more valuable than
> > CASSANDRA-14825,
> > > that are not included in 4.0?
> > > Where do we draw the line?
> > >
> > > I believe that if we were able to answer that question it would
> > suddenly
> > > become much easier to agree on which tickets we put in 4.0.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Sun, Apr 5, 2020 at 1:25 AM Benedict Elliott Smith <
> > benedict@apache.org
> > > >
> > > wrote:
> > >
> > > > There it is. I knew it would show up eventually.
> > > >
> > > > On 04/04/2020, 06:26, "benedict@apache.org" <
> > public@belliottsmith.com>
> > > > wrote:
> > > >
> > > > > scope creep.
> > > >
> > > > I think it is unfair to label this scope creep; it would have
> > to be
> > > > newly considered for 4.0 for it to fall under that umbrella.
> > > >
> > > > I don't personally mind if it lands, but this was discussed
> at
> > length
> > > > on multiple occasions over the past year, and only stalled
> because
> > of a
> > > > combination of lack of etiquette, and a lack of leadership from
> > e.g. PMC
> > > in
> > > > resolving various political questions over the course of events.
> > > >
> > > > I also struggle to see how this would invalidate testing in
> any
> > > > significant way? It doesn't modify any existing behaviour.
> > > >
> > > > ________________________________
> > > > From: Joshua McKenzie <jm...@apache.org>
> > > > Sent: 01 April 2020 19:24
> > > > To: dev@cassandra.apache.org <de...@cassandra.apache.org>
> > > > Subject: Re: server side describe
> > > >
> > > > This looks like a feature that'd potentially invalidate some
> > testing
> > > > that's
> > > > been done and we've been feature frozen for over a year and a
> > half.
> > > > Also:
> > > > scope creep.
> > > >
> > > > My PoV is we hold off. If we get into a cadence of more
> > frequent
> > > > releases
> > > > we'll have it soon enough.
> > > >
> > > > On Wed, Apr 1, 2020 at 3:03 PM <e....@gmail.com>
> wrote:
> > > >
> > > > > Hi,
> > > > > Normally I ping the person on the ticket or in Slack to ask
> > him/her
> > > > for
> > > > > status update and whether I can help. Then probably he/she
> > gives
> > > me a
> > > > > direction.
> > > > > If I can’t find the person anymore, I just use my best
> > judgement
> > > and
> > > > > coordinate with people who might know better than me.
> > > > > For now this strategy worked for me personally.
> > > > > Hope this helps
> > > > > Ekaterina
> > > > >
> > > > > Sent from my iPhone
> > > > >
> > > > > > On 1 Apr 2020, at 14:27, Jon Haddad <jo...@jonhaddad.com>
> > wrote:
> > > > > >
> > > > > > Hey folks,
> > > > > >
> > > > > > I was looking through our open JIRAs and realized we
> hadn't
> > > merged
> > > > in
> > > > > > server side describe calls yet. The ticket died off a
> > ways ago,
> > > > and I
> > > > > > pinged Chris about it yesterday. He's got a lot of his
> > plate and
> > > > won't
> > > > > be
> > > > > > able to work on it anytime soon. I still think we should
> > include
> > > > this in
> > > > > > 4.0.
> > > > > >
> > > > > > From a technical standpoint, It doesn't say much on the
> > ticket
> > > > after
> > > > > Robert
> > > > > > tossed an alternative patch out there. I don't mind
> > reviewing
> > > and
> > > > > merging
> > > > > > either of them, it sounded like both are pretty close to
> > done and
> > > > I think
> > > > > > from the perspective of updating drivers for 4.0 this
> will
> > save
> > > > quite a
> > > > > bit
> > > > > > of time since driver maintainers won't have to add new
> CQL
> > > > generation for
> > > > > > the various new options that have recently appeared.
> > > > > >
> > > > > > Questions:
> > > > > >
> > > > > > * Does anyone have an objection to getting this into 4.0?
> > The
> > > > patches
> > > > > > aren't too huge, I think they're low risk, and also
> fairly
> > high
> > > > reward.
> > > > > > * I don't have an opinion (yet) on Robert's patch vs
> > Chris's,
> > > with
> > > > regard
> > > > > > to which is preferable.
> > > > > > * Since soon after Robert put up his PR he hasn't been
> > around, at
> > > > least
> > > > > as
> > > > > > far as I've seen. How have we dealt with abandoned
> patches
> > > > before? If
> > > > > > we're going to add this in the patch will need some
> > cleanup. Is
> > > it
> > > > > > reasonable to continue someone else's work when they've
> > > > disappeared?
> > > > > >
> > > > > > Jon
> > > > >
> > > > >
> > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail:
> dev-unsubscribe@cassandra.apache.org
> > > > > For additional commands, e-mail:
> > dev-help@cassandra.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > > > For additional commands, e-mail: dev-help@cassandra.apache.org
> > > >
> > > >
> > >
> >
> >
> > --
> > alex p
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
> >
>
Re: server side describe
Posted by Benjamin Lerer <be...@datastax.com>.
Thanks for your answer Alex.
Some of the things we
> have explicitly (as a community) agreed to commit are still in progress,
> including several client protocol changes. And, to my understanding, if
> those are committed, it'll be what community has agreed upon.
>
If the understanding of the community was that this patch was expected to
go in 4.0 then it makes sense to commit it there.
> If the discussion is about whether or not to include _some_ version of the
> patch, I think including it makes sense, especially given the patch was
> there for a while and was not committed for non-technical reasons. If we're
> trying to decide _which_ patch to commit, I'd personally focus on the
> original patch (to foster recognition), get it reviewed, and pick any
> changes that make it better from the follow-up one (to foster
> collaboration).
>
I am fine going through both patches and figuring out a way to merge them
into one if Jon or somebody else is willing to review the output of that
merge
On Thu, Apr 9, 2020 at 12:45 PM Benedict Elliott Smith <be...@apache.org>
wrote:
> +1 all of this
>
> On 09/04/2020, 10:23, "Oleksandr Petrov" <ol...@gmail.com>
> wrote:
>
> > My understanding is that a majority of people ended up in favor of
> a DESCRIBE approach. Robert made a patch for that approach (according
> to
> his comment it was discussed with Chris beforehand).
>
> This sounds like just a switch of API (in other words, you use the same
> string generation, but return it via different means). From the
> (little)
> time I've spent looking at the patch, I remember that there wasn't much
> common code between the two (sorry if I'm remembering it wrong).
>
> If the discussion is about whether or not to include _some_ version of
> the
> patch, I think including it makes sense, especially given the patch was
> there for a while and was not committed for non-technical reasons. If
> we're
> trying to decide _which_ patch to commit, I'd personally focus on the
> original patch (to foster recognition), get it reviewed, and pick any
> changes that make it better from the follow-up one (to foster
> collaboration).
>
> > Where do we draw the line?
>
> I would discuss changes on the case-by-case basis. Some of the things
> we
> have explicitly (as a community) agreed to commit are still in
> progress,
> including several client protocol changes. And, to my understanding, if
> those are committed, it'll be what community has agreed upon. All
> further
> changes that weren't discussed yet - we can talk over. If it's
> something as
> trivial as server-side describe that doesn't risk stability but adds a
> lot
> of value, it may make sense to include. But I woudln't attempt to come
> up
> with a general rule for what we may or may not consider for now.
>
>
> On Mon, Apr 6, 2020 at 3:21 PM Benjamin Lerer <
> benjamin.lerer@datastax.com>
> wrote:
>
> > We have already discussed it for several days and I believe that all
> the
> > points have been brought to the table.
> >
> > I took the time to read CASSANDRA-14825 this morning to understand
> the full
> > story.
> > All the discussion has been about using Virtual Tables versus using
> > DESCRIBE.
> > My understanding is that a majority of people ended up in favor of a
> > DESCRIBE approach (skipping the details on purpose here).
> > Robert made a patch for that approach (according to his comment it
> was
> > discussed with Chris beforehand).
> >
> > The question here is should: we agree to put it in 4.0 even if the
> version
> > is frozen for improvements.
> >
> > My main reason against it is that if we broke the freeze for every
> ticket
> > we believe might be useful we will end up delaying 4.0 a lot.
> > Are there not other tickets that are more valuable than
> CASSANDRA-14825,
> > that are not included in 4.0?
> > Where do we draw the line?
> >
> > I believe that if we were able to answer that question it would
> suddenly
> > become much easier to agree on which tickets we put in 4.0.
> >
> >
> >
> >
> >
> >
> >
> >
> > On Sun, Apr 5, 2020 at 1:25 AM Benedict Elliott Smith <
> benedict@apache.org
> > >
> > wrote:
> >
> > > There it is. I knew it would show up eventually.
> > >
> > > On 04/04/2020, 06:26, "benedict@apache.org" <
> public@belliottsmith.com>
> > > wrote:
> > >
> > > > scope creep.
> > >
> > > I think it is unfair to label this scope creep; it would have
> to be
> > > newly considered for 4.0 for it to fall under that umbrella.
> > >
> > > I don't personally mind if it lands, but this was discussed at
> length
> > > on multiple occasions over the past year, and only stalled because
> of a
> > > combination of lack of etiquette, and a lack of leadership from
> e.g. PMC
> > in
> > > resolving various political questions over the course of events.
> > >
> > > I also struggle to see how this would invalidate testing in any
> > > significant way? It doesn't modify any existing behaviour.
> > >
> > > ________________________________
> > > From: Joshua McKenzie <jm...@apache.org>
> > > Sent: 01 April 2020 19:24
> > > To: dev@cassandra.apache.org <de...@cassandra.apache.org>
> > > Subject: Re: server side describe
> > >
> > > This looks like a feature that'd potentially invalidate some
> testing
> > > that's
> > > been done and we've been feature frozen for over a year and a
> half.
> > > Also:
> > > scope creep.
> > >
> > > My PoV is we hold off. If we get into a cadence of more
> frequent
> > > releases
> > > we'll have it soon enough.
> > >
> > > On Wed, Apr 1, 2020 at 3:03 PM <e....@gmail.com> wrote:
> > >
> > > > Hi,
> > > > Normally I ping the person on the ticket or in Slack to ask
> him/her
> > > for
> > > > status update and whether I can help. Then probably he/she
> gives
> > me a
> > > > direction.
> > > > If I can’t find the person anymore, I just use my best
> judgement
> > and
> > > > coordinate with people who might know better than me.
> > > > For now this strategy worked for me personally.
> > > > Hope this helps
> > > > Ekaterina
> > > >
> > > > Sent from my iPhone
> > > >
> > > > > On 1 Apr 2020, at 14:27, Jon Haddad <jo...@jonhaddad.com>
> wrote:
> > > > >
> > > > > Hey folks,
> > > > >
> > > > > I was looking through our open JIRAs and realized we hadn't
> > merged
> > > in
> > > > > server side describe calls yet. The ticket died off a
> ways ago,
> > > and I
> > > > > pinged Chris about it yesterday. He's got a lot of his
> plate and
> > > won't
> > > > be
> > > > > able to work on it anytime soon. I still think we should
> include
> > > this in
> > > > > 4.0.
> > > > >
> > > > > From a technical standpoint, It doesn't say much on the
> ticket
> > > after
> > > > Robert
> > > > > tossed an alternative patch out there. I don't mind
> reviewing
> > and
> > > > merging
> > > > > either of them, it sounded like both are pretty close to
> done and
> > > I think
> > > > > from the perspective of updating drivers for 4.0 this will
> save
> > > quite a
> > > > bit
> > > > > of time since driver maintainers won't have to add new CQL
> > > generation for
> > > > > the various new options that have recently appeared.
> > > > >
> > > > > Questions:
> > > > >
> > > > > * Does anyone have an objection to getting this into 4.0?
> The
> > > patches
> > > > > aren't too huge, I think they're low risk, and also fairly
> high
> > > reward.
> > > > > * I don't have an opinion (yet) on Robert's patch vs
> Chris's,
> > with
> > > regard
> > > > > to which is preferable.
> > > > > * Since soon after Robert put up his PR he hasn't been
> around, at
> > > least
> > > > as
> > > > > far as I've seen. How have we dealt with abandoned patches
> > > before? If
> > > > > we're going to add this in the patch will need some
> cleanup. Is
> > it
> > > > > reasonable to continue someone else's work when they've
> > > disappeared?
> > > > >
> > > > > Jon
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > > > For additional commands, e-mail:
> dev-help@cassandra.apache.org
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > > For additional commands, e-mail: dev-help@cassandra.apache.org
> > >
> > >
> >
>
>
> --
> alex p
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
Re: server side describe
Posted by Benedict Elliott Smith <be...@apache.org>.
+1 all of this
On 09/04/2020, 10:23, "Oleksandr Petrov" <ol...@gmail.com> wrote:
> My understanding is that a majority of people ended up in favor of
a DESCRIBE approach. Robert made a patch for that approach (according to
his comment it was discussed with Chris beforehand).
This sounds like just a switch of API (in other words, you use the same
string generation, but return it via different means). From the (little)
time I've spent looking at the patch, I remember that there wasn't much
common code between the two (sorry if I'm remembering it wrong).
If the discussion is about whether or not to include _some_ version of the
patch, I think including it makes sense, especially given the patch was
there for a while and was not committed for non-technical reasons. If we're
trying to decide _which_ patch to commit, I'd personally focus on the
original patch (to foster recognition), get it reviewed, and pick any
changes that make it better from the follow-up one (to foster
collaboration).
> Where do we draw the line?
I would discuss changes on the case-by-case basis. Some of the things we
have explicitly (as a community) agreed to commit are still in progress,
including several client protocol changes. And, to my understanding, if
those are committed, it'll be what community has agreed upon. All further
changes that weren't discussed yet - we can talk over. If it's something as
trivial as server-side describe that doesn't risk stability but adds a lot
of value, it may make sense to include. But I woudln't attempt to come up
with a general rule for what we may or may not consider for now.
On Mon, Apr 6, 2020 at 3:21 PM Benjamin Lerer <be...@datastax.com>
wrote:
> We have already discussed it for several days and I believe that all the
> points have been brought to the table.
>
> I took the time to read CASSANDRA-14825 this morning to understand the full
> story.
> All the discussion has been about using Virtual Tables versus using
> DESCRIBE.
> My understanding is that a majority of people ended up in favor of a
> DESCRIBE approach (skipping the details on purpose here).
> Robert made a patch for that approach (according to his comment it was
> discussed with Chris beforehand).
>
> The question here is should: we agree to put it in 4.0 even if the version
> is frozen for improvements.
>
> My main reason against it is that if we broke the freeze for every ticket
> we believe might be useful we will end up delaying 4.0 a lot.
> Are there not other tickets that are more valuable than CASSANDRA-14825,
> that are not included in 4.0?
> Where do we draw the line?
>
> I believe that if we were able to answer that question it would suddenly
> become much easier to agree on which tickets we put in 4.0.
>
>
>
>
>
>
>
>
> On Sun, Apr 5, 2020 at 1:25 AM Benedict Elliott Smith <benedict@apache.org
> >
> wrote:
>
> > There it is. I knew it would show up eventually.
> >
> > On 04/04/2020, 06:26, "benedict@apache.org" <pu...@belliottsmith.com>
> > wrote:
> >
> > > scope creep.
> >
> > I think it is unfair to label this scope creep; it would have to be
> > newly considered for 4.0 for it to fall under that umbrella.
> >
> > I don't personally mind if it lands, but this was discussed at length
> > on multiple occasions over the past year, and only stalled because of a
> > combination of lack of etiquette, and a lack of leadership from e.g. PMC
> in
> > resolving various political questions over the course of events.
> >
> > I also struggle to see how this would invalidate testing in any
> > significant way? It doesn't modify any existing behaviour.
> >
> > ________________________________
> > From: Joshua McKenzie <jm...@apache.org>
> > Sent: 01 April 2020 19:24
> > To: dev@cassandra.apache.org <de...@cassandra.apache.org>
> > Subject: Re: server side describe
> >
> > This looks like a feature that'd potentially invalidate some testing
> > that's
> > been done and we've been feature frozen for over a year and a half.
> > Also:
> > scope creep.
> >
> > My PoV is we hold off. If we get into a cadence of more frequent
> > releases
> > we'll have it soon enough.
> >
> > On Wed, Apr 1, 2020 at 3:03 PM <e....@gmail.com> wrote:
> >
> > > Hi,
> > > Normally I ping the person on the ticket or in Slack to ask him/her
> > for
> > > status update and whether I can help. Then probably he/she gives
> me a
> > > direction.
> > > If I can’t find the person anymore, I just use my best judgement
> and
> > > coordinate with people who might know better than me.
> > > For now this strategy worked for me personally.
> > > Hope this helps
> > > Ekaterina
> > >
> > > Sent from my iPhone
> > >
> > > > On 1 Apr 2020, at 14:27, Jon Haddad <jo...@jonhaddad.com> wrote:
> > > >
> > > > Hey folks,
> > > >
> > > > I was looking through our open JIRAs and realized we hadn't
> merged
> > in
> > > > server side describe calls yet. The ticket died off a ways ago,
> > and I
> > > > pinged Chris about it yesterday. He's got a lot of his plate and
> > won't
> > > be
> > > > able to work on it anytime soon. I still think we should include
> > this in
> > > > 4.0.
> > > >
> > > > From a technical standpoint, It doesn't say much on the ticket
> > after
> > > Robert
> > > > tossed an alternative patch out there. I don't mind reviewing
> and
> > > merging
> > > > either of them, it sounded like both are pretty close to done and
> > I think
> > > > from the perspective of updating drivers for 4.0 this will save
> > quite a
> > > bit
> > > > of time since driver maintainers won't have to add new CQL
> > generation for
> > > > the various new options that have recently appeared.
> > > >
> > > > Questions:
> > > >
> > > > * Does anyone have an objection to getting this into 4.0? The
> > patches
> > > > aren't too huge, I think they're low risk, and also fairly high
> > reward.
> > > > * I don't have an opinion (yet) on Robert's patch vs Chris's,
> with
> > regard
> > > > to which is preferable.
> > > > * Since soon after Robert put up his PR he hasn't been around, at
> > least
> > > as
> > > > far as I've seen. How have we dealt with abandoned patches
> > before? If
> > > > we're going to add this in the patch will need some cleanup. Is
> it
> > > > reasonable to continue someone else's work when they've
> > disappeared?
> > > >
> > > > Jon
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > > For additional commands, e-mail: dev-help@cassandra.apache.org
> > >
> > >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
> >
>
--
alex p
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: server side describe
Posted by Oleksandr Petrov <ol...@gmail.com>.
> My understanding is that a majority of people ended up in favor of
a DESCRIBE approach. Robert made a patch for that approach (according to
his comment it was discussed with Chris beforehand).
This sounds like just a switch of API (in other words, you use the same
string generation, but return it via different means). From the (little)
time I've spent looking at the patch, I remember that there wasn't much
common code between the two (sorry if I'm remembering it wrong).
If the discussion is about whether or not to include _some_ version of the
patch, I think including it makes sense, especially given the patch was
there for a while and was not committed for non-technical reasons. If we're
trying to decide _which_ patch to commit, I'd personally focus on the
original patch (to foster recognition), get it reviewed, and pick any
changes that make it better from the follow-up one (to foster
collaboration).
> Where do we draw the line?
I would discuss changes on the case-by-case basis. Some of the things we
have explicitly (as a community) agreed to commit are still in progress,
including several client protocol changes. And, to my understanding, if
those are committed, it'll be what community has agreed upon. All further
changes that weren't discussed yet - we can talk over. If it's something as
trivial as server-side describe that doesn't risk stability but adds a lot
of value, it may make sense to include. But I woudln't attempt to come up
with a general rule for what we may or may not consider for now.
On Mon, Apr 6, 2020 at 3:21 PM Benjamin Lerer <be...@datastax.com>
wrote:
> We have already discussed it for several days and I believe that all the
> points have been brought to the table.
>
> I took the time to read CASSANDRA-14825 this morning to understand the full
> story.
> All the discussion has been about using Virtual Tables versus using
> DESCRIBE.
> My understanding is that a majority of people ended up in favor of a
> DESCRIBE approach (skipping the details on purpose here).
> Robert made a patch for that approach (according to his comment it was
> discussed with Chris beforehand).
>
> The question here is should: we agree to put it in 4.0 even if the version
> is frozen for improvements.
>
> My main reason against it is that if we broke the freeze for every ticket
> we believe might be useful we will end up delaying 4.0 a lot.
> Are there not other tickets that are more valuable than CASSANDRA-14825,
> that are not included in 4.0?
> Where do we draw the line?
>
> I believe that if we were able to answer that question it would suddenly
> become much easier to agree on which tickets we put in 4.0.
>
>
>
>
>
>
>
>
> On Sun, Apr 5, 2020 at 1:25 AM Benedict Elliott Smith <benedict@apache.org
> >
> wrote:
>
> > There it is. I knew it would show up eventually.
> >
> > On 04/04/2020, 06:26, "benedict@apache.org" <pu...@belliottsmith.com>
> > wrote:
> >
> > > scope creep.
> >
> > I think it is unfair to label this scope creep; it would have to be
> > newly considered for 4.0 for it to fall under that umbrella.
> >
> > I don't personally mind if it lands, but this was discussed at length
> > on multiple occasions over the past year, and only stalled because of a
> > combination of lack of etiquette, and a lack of leadership from e.g. PMC
> in
> > resolving various political questions over the course of events.
> >
> > I also struggle to see how this would invalidate testing in any
> > significant way? It doesn't modify any existing behaviour.
> >
> > ________________________________
> > From: Joshua McKenzie <jm...@apache.org>
> > Sent: 01 April 2020 19:24
> > To: dev@cassandra.apache.org <de...@cassandra.apache.org>
> > Subject: Re: server side describe
> >
> > This looks like a feature that'd potentially invalidate some testing
> > that's
> > been done and we've been feature frozen for over a year and a half.
> > Also:
> > scope creep.
> >
> > My PoV is we hold off. If we get into a cadence of more frequent
> > releases
> > we'll have it soon enough.
> >
> > On Wed, Apr 1, 2020 at 3:03 PM <e....@gmail.com> wrote:
> >
> > > Hi,
> > > Normally I ping the person on the ticket or in Slack to ask him/her
> > for
> > > status update and whether I can help. Then probably he/she gives
> me a
> > > direction.
> > > If I can’t find the person anymore, I just use my best judgement
> and
> > > coordinate with people who might know better than me.
> > > For now this strategy worked for me personally.
> > > Hope this helps
> > > Ekaterina
> > >
> > > Sent from my iPhone
> > >
> > > > On 1 Apr 2020, at 14:27, Jon Haddad <jo...@jonhaddad.com> wrote:
> > > >
> > > > Hey folks,
> > > >
> > > > I was looking through our open JIRAs and realized we hadn't
> merged
> > in
> > > > server side describe calls yet. The ticket died off a ways ago,
> > and I
> > > > pinged Chris about it yesterday. He's got a lot of his plate and
> > won't
> > > be
> > > > able to work on it anytime soon. I still think we should include
> > this in
> > > > 4.0.
> > > >
> > > > From a technical standpoint, It doesn't say much on the ticket
> > after
> > > Robert
> > > > tossed an alternative patch out there. I don't mind reviewing
> and
> > > merging
> > > > either of them, it sounded like both are pretty close to done and
> > I think
> > > > from the perspective of updating drivers for 4.0 this will save
> > quite a
> > > bit
> > > > of time since driver maintainers won't have to add new CQL
> > generation for
> > > > the various new options that have recently appeared.
> > > >
> > > > Questions:
> > > >
> > > > * Does anyone have an objection to getting this into 4.0? The
> > patches
> > > > aren't too huge, I think they're low risk, and also fairly high
> > reward.
> > > > * I don't have an opinion (yet) on Robert's patch vs Chris's,
> with
> > regard
> > > > to which is preferable.
> > > > * Since soon after Robert put up his PR he hasn't been around, at
> > least
> > > as
> > > > far as I've seen. How have we dealt with abandoned patches
> > before? If
> > > > we're going to add this in the patch will need some cleanup. Is
> it
> > > > reasonable to continue someone else's work when they've
> > disappeared?
> > > >
> > > > Jon
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > > For additional commands, e-mail: dev-help@cassandra.apache.org
> > >
> > >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
> >
>
--
alex p
Re: server side describe
Posted by Benjamin Lerer <be...@datastax.com>.
We have already discussed it for several days and I believe that all the
points have been brought to the table.
I took the time to read CASSANDRA-14825 this morning to understand the full
story.
All the discussion has been about using Virtual Tables versus using
DESCRIBE.
My understanding is that a majority of people ended up in favor of a
DESCRIBE approach (skipping the details on purpose here).
Robert made a patch for that approach (according to his comment it was
discussed with Chris beforehand).
The question here is should: we agree to put it in 4.0 even if the version
is frozen for improvements.
My main reason against it is that if we broke the freeze for every ticket
we believe might be useful we will end up delaying 4.0 a lot.
Are there not other tickets that are more valuable than CASSANDRA-14825,
that are not included in 4.0?
Where do we draw the line?
I believe that if we were able to answer that question it would suddenly
become much easier to agree on which tickets we put in 4.0.
On Sun, Apr 5, 2020 at 1:25 AM Benedict Elliott Smith <be...@apache.org>
wrote:
> There it is. I knew it would show up eventually.
>
> On 04/04/2020, 06:26, "benedict@apache.org" <pu...@belliottsmith.com>
> wrote:
>
> > scope creep.
>
> I think it is unfair to label this scope creep; it would have to be
> newly considered for 4.0 for it to fall under that umbrella.
>
> I don't personally mind if it lands, but this was discussed at length
> on multiple occasions over the past year, and only stalled because of a
> combination of lack of etiquette, and a lack of leadership from e.g. PMC in
> resolving various political questions over the course of events.
>
> I also struggle to see how this would invalidate testing in any
> significant way? It doesn't modify any existing behaviour.
>
> ________________________________
> From: Joshua McKenzie <jm...@apache.org>
> Sent: 01 April 2020 19:24
> To: dev@cassandra.apache.org <de...@cassandra.apache.org>
> Subject: Re: server side describe
>
> This looks like a feature that'd potentially invalidate some testing
> that's
> been done and we've been feature frozen for over a year and a half.
> Also:
> scope creep.
>
> My PoV is we hold off. If we get into a cadence of more frequent
> releases
> we'll have it soon enough.
>
> On Wed, Apr 1, 2020 at 3:03 PM <e....@gmail.com> wrote:
>
> > Hi,
> > Normally I ping the person on the ticket or in Slack to ask him/her
> for
> > status update and whether I can help. Then probably he/she gives me a
> > direction.
> > If I can’t find the person anymore, I just use my best judgement and
> > coordinate with people who might know better than me.
> > For now this strategy worked for me personally.
> > Hope this helps
> > Ekaterina
> >
> > Sent from my iPhone
> >
> > > On 1 Apr 2020, at 14:27, Jon Haddad <jo...@jonhaddad.com> wrote:
> > >
> > > Hey folks,
> > >
> > > I was looking through our open JIRAs and realized we hadn't merged
> in
> > > server side describe calls yet. The ticket died off a ways ago,
> and I
> > > pinged Chris about it yesterday. He's got a lot of his plate and
> won't
> > be
> > > able to work on it anytime soon. I still think we should include
> this in
> > > 4.0.
> > >
> > > From a technical standpoint, It doesn't say much on the ticket
> after
> > Robert
> > > tossed an alternative patch out there. I don't mind reviewing and
> > merging
> > > either of them, it sounded like both are pretty close to done and
> I think
> > > from the perspective of updating drivers for 4.0 this will save
> quite a
> > bit
> > > of time since driver maintainers won't have to add new CQL
> generation for
> > > the various new options that have recently appeared.
> > >
> > > Questions:
> > >
> > > * Does anyone have an objection to getting this into 4.0? The
> patches
> > > aren't too huge, I think they're low risk, and also fairly high
> reward.
> > > * I don't have an opinion (yet) on Robert's patch vs Chris's, with
> regard
> > > to which is preferable.
> > > * Since soon after Robert put up his PR he hasn't been around, at
> least
> > as
> > > far as I've seen. How have we dealt with abandoned patches
> before? If
> > > we're going to add this in the patch will need some cleanup. Is it
> > > reasonable to continue someone else's work when they've
> disappeared?
> > >
> > > Jon
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
Re: server side describe
Posted by Benedict Elliott Smith <be...@apache.org>.
There it is. I knew it would show up eventually.
On 04/04/2020, 06:26, "benedict@apache.org" <pu...@belliottsmith.com> wrote:
> scope creep.
I think it is unfair to label this scope creep; it would have to be newly considered for 4.0 for it to fall under that umbrella.
I don't personally mind if it lands, but this was discussed at length on multiple occasions over the past year, and only stalled because of a combination of lack of etiquette, and a lack of leadership from e.g. PMC in resolving various political questions over the course of events.
I also struggle to see how this would invalidate testing in any significant way? It doesn't modify any existing behaviour.
________________________________
From: Joshua McKenzie <jm...@apache.org>
Sent: 01 April 2020 19:24
To: dev@cassandra.apache.org <de...@cassandra.apache.org>
Subject: Re: server side describe
This looks like a feature that'd potentially invalidate some testing that's
been done and we've been feature frozen for over a year and a half. Also:
scope creep.
My PoV is we hold off. If we get into a cadence of more frequent releases
we'll have it soon enough.
On Wed, Apr 1, 2020 at 3:03 PM <e....@gmail.com> wrote:
> Hi,
> Normally I ping the person on the ticket or in Slack to ask him/her for
> status update and whether I can help. Then probably he/she gives me a
> direction.
> If I can’t find the person anymore, I just use my best judgement and
> coordinate with people who might know better than me.
> For now this strategy worked for me personally.
> Hope this helps
> Ekaterina
>
> Sent from my iPhone
>
> > On 1 Apr 2020, at 14:27, Jon Haddad <jo...@jonhaddad.com> wrote:
> >
> > Hey folks,
> >
> > I was looking through our open JIRAs and realized we hadn't merged in
> > server side describe calls yet. The ticket died off a ways ago, and I
> > pinged Chris about it yesterday. He's got a lot of his plate and won't
> be
> > able to work on it anytime soon. I still think we should include this in
> > 4.0.
> >
> > From a technical standpoint, It doesn't say much on the ticket after
> Robert
> > tossed an alternative patch out there. I don't mind reviewing and
> merging
> > either of them, it sounded like both are pretty close to done and I think
> > from the perspective of updating drivers for 4.0 this will save quite a
> bit
> > of time since driver maintainers won't have to add new CQL generation for
> > the various new options that have recently appeared.
> >
> > Questions:
> >
> > * Does anyone have an objection to getting this into 4.0? The patches
> > aren't too huge, I think they're low risk, and also fairly high reward.
> > * I don't have an opinion (yet) on Robert's patch vs Chris's, with regard
> > to which is preferable.
> > * Since soon after Robert put up his PR he hasn't been around, at least
> as
> > far as I've seen. How have we dealt with abandoned patches before? If
> > we're going to add this in the patch will need some cleanup. Is it
> > reasonable to continue someone else's work when they've disappeared?
> >
> > Jon
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: server side describe
Posted by "benedict@apache.org" <pu...@belliottsmith.com>.
> scope creep.
I think it is unfair to label this scope creep; it would have to be newly considered for 4.0 for it to fall under that umbrella.
I don't personally mind if it lands, but this was discussed at length on multiple occasions over the past year, and only stalled because of a combination of lack of etiquette, and a lack of leadership from e.g. PMC in resolving various political questions over the course of events.
I also struggle to see how this would invalidate testing in any significant way? It doesn't modify any existing behaviour.
________________________________
From: Joshua McKenzie <jm...@apache.org>
Sent: 01 April 2020 19:24
To: dev@cassandra.apache.org <de...@cassandra.apache.org>
Subject: Re: server side describe
This looks like a feature that'd potentially invalidate some testing that's
been done and we've been feature frozen for over a year and a half. Also:
scope creep.
My PoV is we hold off. If we get into a cadence of more frequent releases
we'll have it soon enough.
On Wed, Apr 1, 2020 at 3:03 PM <e....@gmail.com> wrote:
> Hi,
> Normally I ping the person on the ticket or in Slack to ask him/her for
> status update and whether I can help. Then probably he/she gives me a
> direction.
> If I can’t find the person anymore, I just use my best judgement and
> coordinate with people who might know better than me.
> For now this strategy worked for me personally.
> Hope this helps
> Ekaterina
>
> Sent from my iPhone
>
> > On 1 Apr 2020, at 14:27, Jon Haddad <jo...@jonhaddad.com> wrote:
> >
> > Hey folks,
> >
> > I was looking through our open JIRAs and realized we hadn't merged in
> > server side describe calls yet. The ticket died off a ways ago, and I
> > pinged Chris about it yesterday. He's got a lot of his plate and won't
> be
> > able to work on it anytime soon. I still think we should include this in
> > 4.0.
> >
> > From a technical standpoint, It doesn't say much on the ticket after
> Robert
> > tossed an alternative patch out there. I don't mind reviewing and
> merging
> > either of them, it sounded like both are pretty close to done and I think
> > from the perspective of updating drivers for 4.0 this will save quite a
> bit
> > of time since driver maintainers won't have to add new CQL generation for
> > the various new options that have recently appeared.
> >
> > Questions:
> >
> > * Does anyone have an objection to getting this into 4.0? The patches
> > aren't too huge, I think they're low risk, and also fairly high reward.
> > * I don't have an opinion (yet) on Robert's patch vs Chris's, with regard
> > to which is preferable.
> > * Since soon after Robert put up his PR he hasn't been around, at least
> as
> > far as I've seen. How have we dealt with abandoned patches before? If
> > we're going to add this in the patch will need some cleanup. Is it
> > reasonable to continue someone else's work when they've disappeared?
> >
> > Jon
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
Re: server side describe
Posted by Joshua McKenzie <jm...@apache.org>.
This looks like a feature that'd potentially invalidate some testing that's
been done and we've been feature frozen for over a year and a half. Also:
scope creep.
My PoV is we hold off. If we get into a cadence of more frequent releases
we'll have it soon enough.
On Wed, Apr 1, 2020 at 3:03 PM <e....@gmail.com> wrote:
> Hi,
> Normally I ping the person on the ticket or in Slack to ask him/her for
> status update and whether I can help. Then probably he/she gives me a
> direction.
> If I can’t find the person anymore, I just use my best judgement and
> coordinate with people who might know better than me.
> For now this strategy worked for me personally.
> Hope this helps
> Ekaterina
>
> Sent from my iPhone
>
> > On 1 Apr 2020, at 14:27, Jon Haddad <jo...@jonhaddad.com> wrote:
> >
> > Hey folks,
> >
> > I was looking through our open JIRAs and realized we hadn't merged in
> > server side describe calls yet. The ticket died off a ways ago, and I
> > pinged Chris about it yesterday. He's got a lot of his plate and won't
> be
> > able to work on it anytime soon. I still think we should include this in
> > 4.0.
> >
> > From a technical standpoint, It doesn't say much on the ticket after
> Robert
> > tossed an alternative patch out there. I don't mind reviewing and
> merging
> > either of them, it sounded like both are pretty close to done and I think
> > from the perspective of updating drivers for 4.0 this will save quite a
> bit
> > of time since driver maintainers won't have to add new CQL generation for
> > the various new options that have recently appeared.
> >
> > Questions:
> >
> > * Does anyone have an objection to getting this into 4.0? The patches
> > aren't too huge, I think they're low risk, and also fairly high reward.
> > * I don't have an opinion (yet) on Robert's patch vs Chris's, with regard
> > to which is preferable.
> > * Since soon after Robert put up his PR he hasn't been around, at least
> as
> > far as I've seen. How have we dealt with abandoned patches before? If
> > we're going to add this in the patch will need some cleanup. Is it
> > reasonable to continue someone else's work when they've disappeared?
> >
> > Jon
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
Re: server side describe
Posted by e....@gmail.com.
Hi,
Normally I ping the person on the ticket or in Slack to ask him/her for status update and whether I can help. Then probably he/she gives me a direction.
If I can’t find the person anymore, I just use my best judgement and coordinate with people who might know better than me.
For now this strategy worked for me personally.
Hope this helps
Ekaterina
Sent from my iPhone
> On 1 Apr 2020, at 14:27, Jon Haddad <jo...@jonhaddad.com> wrote:
>
> Hey folks,
>
> I was looking through our open JIRAs and realized we hadn't merged in
> server side describe calls yet. The ticket died off a ways ago, and I
> pinged Chris about it yesterday. He's got a lot of his plate and won't be
> able to work on it anytime soon. I still think we should include this in
> 4.0.
>
> From a technical standpoint, It doesn't say much on the ticket after Robert
> tossed an alternative patch out there. I don't mind reviewing and merging
> either of them, it sounded like both are pretty close to done and I think
> from the perspective of updating drivers for 4.0 this will save quite a bit
> of time since driver maintainers won't have to add new CQL generation for
> the various new options that have recently appeared.
>
> Questions:
>
> * Does anyone have an objection to getting this into 4.0? The patches
> aren't too huge, I think they're low risk, and also fairly high reward.
> * I don't have an opinion (yet) on Robert's patch vs Chris's, with regard
> to which is preferable.
> * Since soon after Robert put up his PR he hasn't been around, at least as
> far as I've seen. How have we dealt with abandoned patches before? If
> we're going to add this in the patch will need some cleanup. Is it
> reasonable to continue someone else's work when they've disappeared?
>
> Jon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: server side describe
Posted by Dinesh Joshi <dj...@apache.org>.
+1. My preference is to have `DESCRIBE` CQL statement.
Dinesh
> On Apr 1, 2020, at 11:33 AM, Nate McCall <zz...@gmail.com> wrote:
>
> I think part of being a modern database is not relying on drivers/clients
> to idiomatically rebuild the schema.
>
> Thanks for bringing it up, Jon - huge +1 on merging (some form) of this.
>
> On Thu, Apr 2, 2020 at 7:27 AM Jon Haddad <jo...@jonhaddad.com> wrote:
>
>> Hey folks,
>>
>> I was looking through our open JIRAs and realized we hadn't merged in
>> server side describe calls yet. The ticket died off a ways ago, and I
>> pinged Chris about it yesterday. He's got a lot of his plate and won't be
>> able to work on it anytime soon. I still think we should include this in
>> 4.0.
>>
>> From a technical standpoint, It doesn't say much on the ticket after Robert
>> tossed an alternative patch out there. I don't mind reviewing and merging
>> either of them, it sounded like both are pretty close to done and I think
>> from the perspective of updating drivers for 4.0 this will save quite a bit
>> of time since driver maintainers won't have to add new CQL generation for
>> the various new options that have recently appeared.
>>
>> Questions:
>>
>> * Does anyone have an objection to getting this into 4.0? The patches
>> aren't too huge, I think they're low risk, and also fairly high reward.
>> * I don't have an opinion (yet) on Robert's patch vs Chris's, with regard
>> to which is preferable.
>> * Since soon after Robert put up his PR he hasn't been around, at least as
>> far as I've seen. How have we dealt with abandoned patches before? If
>> we're going to add this in the patch will need some cleanup. Is it
>> reasonable to continue someone else's work when they've disappeared?
>>
>> Jon
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: server side describe
Posted by Nate McCall <zz...@gmail.com>.
That's totally fair - but this brings us back to needing a discussion and
plan on prioritization for what 4.next looks like.
On Thu, Apr 2, 2020 at 7:41 AM Brandon Williams <dr...@gmail.com> wrote:
> I want to start by saying I don't disagree with you on this issue.
>
> But, I do want to highlight that feature creep is real, and hurting
> our impending release.
>
>
> On Wed, Apr 1, 2020 at 1:33 PM Nate McCall <zz...@gmail.com> wrote:
> >
> > I think part of being a modern database is not relying on drivers/clients
> > to idiomatically rebuild the schema.
> >
> > Thanks for bringing it up, Jon - huge +1 on merging (some form) of this.
> >
> > On Thu, Apr 2, 2020 at 7:27 AM Jon Haddad <jo...@jonhaddad.com> wrote:
> >
> > > Hey folks,
> > >
> > > I was looking through our open JIRAs and realized we hadn't merged in
> > > server side describe calls yet. The ticket died off a ways ago, and I
> > > pinged Chris about it yesterday. He's got a lot of his plate and
> won't be
> > > able to work on it anytime soon. I still think we should include this
> in
> > > 4.0.
> > >
> > > From a technical standpoint, It doesn't say much on the ticket after
> Robert
> > > tossed an alternative patch out there. I don't mind reviewing and
> merging
> > > either of them, it sounded like both are pretty close to done and I
> think
> > > from the perspective of updating drivers for 4.0 this will save quite
> a bit
> > > of time since driver maintainers won't have to add new CQL generation
> for
> > > the various new options that have recently appeared.
> > >
> > > Questions:
> > >
> > > * Does anyone have an objection to getting this into 4.0? The patches
> > > aren't too huge, I think they're low risk, and also fairly high reward.
> > > * I don't have an opinion (yet) on Robert's patch vs Chris's, with
> regard
> > > to which is preferable.
> > > * Since soon after Robert put up his PR he hasn't been around, at
> least as
> > > far as I've seen. How have we dealt with abandoned patches before? If
> > > we're going to add this in the patch will need some cleanup. Is it
> > > reasonable to continue someone else's work when they've disappeared?
> > >
> > > Jon
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
Re: server side describe
Posted by Brandon Williams <dr...@gmail.com>.
I want to start by saying I don't disagree with you on this issue.
But, I do want to highlight that feature creep is real, and hurting
our impending release.
On Wed, Apr 1, 2020 at 1:33 PM Nate McCall <zz...@gmail.com> wrote:
>
> I think part of being a modern database is not relying on drivers/clients
> to idiomatically rebuild the schema.
>
> Thanks for bringing it up, Jon - huge +1 on merging (some form) of this.
>
> On Thu, Apr 2, 2020 at 7:27 AM Jon Haddad <jo...@jonhaddad.com> wrote:
>
> > Hey folks,
> >
> > I was looking through our open JIRAs and realized we hadn't merged in
> > server side describe calls yet. The ticket died off a ways ago, and I
> > pinged Chris about it yesterday. He's got a lot of his plate and won't be
> > able to work on it anytime soon. I still think we should include this in
> > 4.0.
> >
> > From a technical standpoint, It doesn't say much on the ticket after Robert
> > tossed an alternative patch out there. I don't mind reviewing and merging
> > either of them, it sounded like both are pretty close to done and I think
> > from the perspective of updating drivers for 4.0 this will save quite a bit
> > of time since driver maintainers won't have to add new CQL generation for
> > the various new options that have recently appeared.
> >
> > Questions:
> >
> > * Does anyone have an objection to getting this into 4.0? The patches
> > aren't too huge, I think they're low risk, and also fairly high reward.
> > * I don't have an opinion (yet) on Robert's patch vs Chris's, with regard
> > to which is preferable.
> > * Since soon after Robert put up his PR he hasn't been around, at least as
> > far as I've seen. How have we dealt with abandoned patches before? If
> > we're going to add this in the patch will need some cleanup. Is it
> > reasonable to continue someone else's work when they've disappeared?
> >
> > Jon
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: server side describe
Posted by Nate McCall <zz...@gmail.com>.
I think part of being a modern database is not relying on drivers/clients
to idiomatically rebuild the schema.
Thanks for bringing it up, Jon - huge +1 on merging (some form) of this.
On Thu, Apr 2, 2020 at 7:27 AM Jon Haddad <jo...@jonhaddad.com> wrote:
> Hey folks,
>
> I was looking through our open JIRAs and realized we hadn't merged in
> server side describe calls yet. The ticket died off a ways ago, and I
> pinged Chris about it yesterday. He's got a lot of his plate and won't be
> able to work on it anytime soon. I still think we should include this in
> 4.0.
>
> From a technical standpoint, It doesn't say much on the ticket after Robert
> tossed an alternative patch out there. I don't mind reviewing and merging
> either of them, it sounded like both are pretty close to done and I think
> from the perspective of updating drivers for 4.0 this will save quite a bit
> of time since driver maintainers won't have to add new CQL generation for
> the various new options that have recently appeared.
>
> Questions:
>
> * Does anyone have an objection to getting this into 4.0? The patches
> aren't too huge, I think they're low risk, and also fairly high reward.
> * I don't have an opinion (yet) on Robert's patch vs Chris's, with regard
> to which is preferable.
> * Since soon after Robert put up his PR he hasn't been around, at least as
> far as I've seen. How have we dealt with abandoned patches before? If
> we're going to add this in the patch will need some cleanup. Is it
> reasonable to continue someone else's work when they've disappeared?
>
> Jon
>