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 <clohfin...@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.le...@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 < > > bened...@apache.org> > > wrote: > > > > > +1 all of this > > > > > > On 09/04/2020, 10:23, "Oleksandr Petrov" <oleksandr.pet...@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.le...@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 < > > > bened...@apache.org > > > > > > > > > wrote: > > > > > > > > > There it is. I knew it would show up eventually. > > > > > > > > > > On 04/04/2020, 06:26, "bened...@apache.org" < > > > pub...@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 <jmcken...@apache.org> > > > > > Sent: 01 April 2020 19:24 > > > > > To: dev@cassandra.apache.org <dev@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.dimitr...@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 <j...@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-unsubscr...@cassandra.apache.org > > > > > > For additional commands, e-mail: > > > dev-h...@cassandra.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > > > > > > > > > > > > > > > > -- > > > alex p > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > >
