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 > > > > >
