Re: Proposal: freeze Thrift starting with 2.1.0
There was a paging bug in 2.0 and a user just reported a bug sorting a one row dataset. So if you want to argue cql has surpassed thrift in all ways, one way it clearly has not is correctness. To demonatrate, search the changelog for cql bugs that return wrong result. Then do the same search for thrift bugs that return the wrong result and compare. If nubes to the ml can pick up bugs and performance regressions it is a serious issue. On Wednesday, March 12, 2014, Jonathan Ellis wrote: > I don't know if an IN query already does this without source diving, > but it could certainly do so without needing extra syntax. > > On Wed, Mar 12, 2014 at 7:16 PM, Nicolas Favre-Felix wrote: >>> If any new use cases >>> come to light that can be done with Thrift but not CQL, we will commit >>> to supporting those in CQL. >> >> Hello, >> >> (going back to the original topic...) >> >> I just wanted to point out that there is in my opinion an important >> use case that is doable in Thrift but not in CQL, which is to fetch >> several CQL rows from the same partition in a single isolated read. We >> lose the benefit of partition-level isolation if there is no way to >> read rows together. >> Of course we can perform range queries and even scan over >> multi-dimensional clustering keys with CASSANDRA-4851, but we still >> can't fetch rows using a set of clustering keys. >> >> I couldn't find a JIRA for this feature, does anyone know if there is one? >> >> Cheers, >> Nicolas >> >> -- >> For what it's worth, +1 on freezing Thrift. > > > > -- > Jonathan Ellis > Project Chair, Apache Cassandra > co-founder, http://www.datastax.com > @spyced > -- Sorry this was sent from mobile. Will do less grammar and spell check than usual.
Re: Proposal: freeze Thrift starting with 2.1.0
Ed- I understand and respect your enthusiasm for Thrift, but it's ship has sailed. Yes- if you understand the low level thrift API I'm sure you can have a rewarding experience, but as someone who wrote a client and had to abstract thrift...I don't have many kind words, and I certainly have less hair on my head... Every line of code ever written has the chance of bugs and thankfully this project has a super dedicated group of people who are very very responsive at fixing those. The sorting and paging bugs might not have happened in thrift because that logic is and has always been pushed onto the client. (Where there are also lots of bugs). I like the model where the bug is fixed once for all languages and clients personally... CQL has worked for me in 9 different sets of application logic as of now..and C* is more accessible to others because of it. Application code is simpler, client code is simpler, learning curve for new uses is easier. Win. Win. Win. IMHO, If you put 1/4 of the energy into CQL that you do into fighting for Thrift, I'm scared to think how amazing CQL would be. Best, Michael > On Mar 13, 2014, at 5:59 AM, "Edward Capriolo" wrote: > > There was a paging bug in 2.0 and a user just reported a bug sorting a one > row dataset. > > So if you want to argue cql has surpassed thrift in all ways, one way it > clearly has not is correctness. > > To demonatrate, search the changelog for cql bugs that return wrong result. > Then do the same search for thrift bugs that return the wrong result and > compare. > > If nubes to the ml can pick up bugs and performance regressions it is a > serious issue. > >> On Wednesday, March 12, 2014, Jonathan Ellis wrote: >> I don't know if an IN query already does this without source diving, >> but it could certainly do so without needing extra syntax. >> >> On Wed, Mar 12, 2014 at 7:16 PM, Nicolas Favre-Felix > wrote: If any new use cases come to light that can be done with Thrift but not CQL, we will commit to supporting those in CQL. >>> >>> Hello, >>> >>> (going back to the original topic...) >>> >>> I just wanted to point out that there is in my opinion an important >>> use case that is doable in Thrift but not in CQL, which is to fetch >>> several CQL rows from the same partition in a single isolated read. We >>> lose the benefit of partition-level isolation if there is no way to >>> read rows together. >>> Of course we can perform range queries and even scan over >>> multi-dimensional clustering keys with CASSANDRA-4851, but we still >>> can't fetch rows using a set of clustering keys. >>> >>> I couldn't find a JIRA for this feature, does anyone know if there is > one? >>> >>> Cheers, >>> Nicolas >>> >>> -- >>> For what it's worth, +1 on freezing Thrift. >> >> >> >> -- >> Jonathan Ellis >> Project Chair, Apache Cassandra >> co-founder, http://www.datastax.com >> @spyced > > -- > Sorry this was sent from mobile. Will do less grammar and spell check than > usual. === JOIN US! Live webinar featuring 451 Research & West Windsor Township: Best Practices in Security Convergence March 18 at 10am PDT. RSVP at http://www.barracuda.com/451webinar
Re: Proposal: freeze Thrift starting with 2.1.0
"IMHO, If you put 1/4 of the energy into CQL that you do into fighting for Thrift, I'm scared to think how amazing CQL would be." I was just recently putting my energy into 4 thrift tickets, I then was planning to help out on some CQL issues. But then this happened which I feel was directly aimed at my efforts has left a very bitter taste in my mouth. Open source projects should not herd people into supporting only the things that a specific group of people want. To give you an example of this this conversation resulted in the creation of this ticket https://issues.apache.org/jira/browse/CASSANDRA-6846 One of the committers ran over to the ticket and dropped a -1 on it right away. "I'm definitively -1 on putting any type of contract on the internals. They are called internals for a reason, and if rewriting it all entirely tomorrow is best for Cassandra, we should have the possibility to do so. And if we're creating a new abstraction on top of it, well, we're just creating a new API, and well, I really thing we should focus on having just one API to Cassandra and focus efforts there." This is not open source this is stalin source. On Thu, Mar 13, 2014 at 9:09 AM, Michael Kjellman wrote: > Ed- > > I understand and respect your enthusiasm for Thrift, but it's ship has > sailed. Yes- if you understand the low level thrift API I'm sure you can > have a rewarding experience, but as someone who wrote a client and had to > abstract thrift...I don't have many kind words, and I certainly have less > hair on my head... > > Every line of code ever written has the chance of bugs and thankfully this > project has a super dedicated group of people who are very very responsive > at fixing those. The sorting and paging bugs might not have happened in > thrift because that logic is and has always been pushed onto the client. > (Where there are also lots of bugs). I like the model where the bug is > fixed once for all languages and clients personally... > > CQL has worked for me in 9 different sets of application logic as of > now..and C* is more accessible to others because of it. Application code is > simpler, client code is simpler, learning curve for new uses is easier. > Win. Win. Win. > > IMHO, If you put 1/4 of the energy into CQL that you do into fighting for > Thrift, I'm scared to think how amazing CQL would be. > > Best, > Michael > > > On Mar 13, 2014, at 5:59 AM, "Edward Capriolo" > wrote: > > > > There was a paging bug in 2.0 and a user just reported a bug sorting a > one > > row dataset. > > > > So if you want to argue cql has surpassed thrift in all ways, one way it > > clearly has not is correctness. > > > > To demonatrate, search the changelog for cql bugs that return wrong > result. > > Then do the same search for thrift bugs that return the wrong result and > > compare. > > > > If nubes to the ml can pick up bugs and performance regressions it is a > > serious issue. > > > >> On Wednesday, March 12, 2014, Jonathan Ellis wrote: > >> I don't know if an IN query already does this without source diving, > >> but it could certainly do so without needing extra syntax. > >> > >> On Wed, Mar 12, 2014 at 7:16 PM, Nicolas Favre-Felix > > > wrote: > If any new use cases > come to light that can be done with Thrift but not CQL, we will commit > to supporting those in CQL. > >>> > >>> Hello, > >>> > >>> (going back to the original topic...) > >>> > >>> I just wanted to point out that there is in my opinion an important > >>> use case that is doable in Thrift but not in CQL, which is to fetch > >>> several CQL rows from the same partition in a single isolated read. We > >>> lose the benefit of partition-level isolation if there is no way to > >>> read rows together. > >>> Of course we can perform range queries and even scan over > >>> multi-dimensional clustering keys with CASSANDRA-4851, but we still > >>> can't fetch rows using a set of clustering keys. > >>> > >>> I couldn't find a JIRA for this feature, does anyone know if there is > > one? > >>> > >>> Cheers, > >>> Nicolas > >>> > >>> -- > >>> For what it's worth, +1 on freezing Thrift. > >> > >> > >> > >> -- > >> Jonathan Ellis > >> Project Chair, Apache Cassandra > >> co-founder, http://www.datastax.com > >> @spyced > > > > -- > > Sorry this was sent from mobile. Will do less grammar and spell check > than > > usual. > > === > > > > JOIN US! Live webinar featuring 451 Research & West Windsor Township: > > Best Practices in Security Convergence > > March 18 at 10am PDT. > > RSVP at http://www.barracuda.com/451webinar > > >
Re: Proposal: freeze Thrift starting with 2.1.0
After discussing this the past few days with a couple of folks, yes, I don't think maintaining the currently incubating Usergrid ( https://usergrid.incubator.apache.org/) will be possible. Basically, how would you do what are essentially container collections of arbitrary runtime-definable UDTs? With everything in a virtual keyspace? Think about how we got the mongodb emulator working. Can you really do this with CQL? Apigee is currently running several instances of this system at scale for a number of very large clients. The main public cluster behind the AppServices product has "many tens of thousands" of tenants. Again, in all seriousness, is this dynamic a model possible via CQL? Granted, we may be an edge case at this point and maintaing a large chunk of code solely for that type of function is just bad software. Hence my desire to assist with https://issues.apache.org/jira/browse/CASSANDRA-6846.
Re: Proposal: freeze Thrift starting with 2.1.0
You should probably give more details of those two data models for those of us who have contributed neither to usergrid nor the mongodb emulator. :) On Thu, Mar 13, 2014 at 9:10 AM, Nate McCall wrote: > After discussing this the past few days with a couple of folks, yes, I > don't think maintaining the currently incubating Usergrid ( > https://usergrid.incubator.apache.org/) will be possible. > > Basically, how would you do what are essentially container collections of > arbitrary runtime-definable UDTs? With everything in a virtual keyspace? > Think about how we got the mongodb emulator working. Can you really do this > with CQL? > > Apigee is currently running several instances of this system at scale for a > number of very large clients. The main public cluster behind the > AppServices product has "many tens of thousands" of tenants. > > Again, in all seriousness, is this dynamic a model possible via CQL? > > Granted, we may be an edge case at this point and maintaing a large chunk > of code solely for that type of function is just bad software. Hence my > desire to assist with https://issues.apache.org/jira/browse/CASSANDRA-6846. -- Jonathan Ellis Project Chair, Apache Cassandra co-founder, http://www.datastax.com @spyced
Re: Proposal: freeze Thrift starting with 2.1.0
Sure:
https://speakerdeck.com/sungjuly/apache-usergrid-internal
Slide #21 and on goes over the entity model in detail. Particularly
interesting:
#36
#40
#55-#61
Essentially, Usergrid supports *all* of the basic mongo CRUD operations on
top of Cassandra, passing all of their test cases that don't use any
out-of-the-way functions. Would it be possible to build something similar
*solely* with CQL?
Again, we are at thought exercise at this point, but you through the
gauntlet down :)
I'm fine with Thrift going away - I get the reasoning there. I just want to
be able to hack against ("against", not "on") internals more easily.
On Thu, Mar 13, 2014 at 9:30 AM, Jonathan Ellis wrote:
> You should probably give more details of those two data models for
> those of us who have contributed neither to usergrid nor the mongodb
> emulator. :)
>
> On Thu, Mar 13, 2014 at 9:10 AM, Nate McCall
> wrote:
> > After discussing this the past few days with a couple of folks, yes, I
> > don't think maintaining the currently incubating Usergrid (
> > https://usergrid.incubator.apache.org/) will be possible.
> >
> > Basically, how would you do what are essentially container collections of
> > arbitrary runtime-definable UDTs? With everything in a virtual keyspace?
> > Think about how we got the mongodb emulator working. Can you really do
> this
> > with CQL?
> >
> > Apigee is currently running several instances of this system at scale
> for a
> > number of very large clients. The main public cluster behind the
> > AppServices product has "many tens of thousands" of tenants.
> >
> > Again, in all seriousness, is this dynamic a model possible via CQL?
> >
> > Granted, we may be an edge case at this point and maintaing a large chunk
> > of code solely for that type of function is just bad software. Hence my
> > desire to assist with
> https://issues.apache.org/jira/browse/CASSANDRA-6846.
>
>
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
>
--
-
Nate McCall
Austin, TX
@zznate
Co-Founder & Sr. Technical Consultant
Apache Cassandra Consulting
http://www.thelastpickle.com
Re: Proposal: freeze Thrift starting with 2.1.0
On Thu, Mar 13, 2014 at 4:14 PM, Nate McCall wrote:
> Sure:
> https://speakerdeck.com/sungjuly/apache-usergrid-internal
>
> Slide #21 and on goes over the entity model in detail. Particularly
> interesting:
> #36
> #40
> #55-#61
>
> Essentially, Usergrid supports *all* of the basic mongo CRUD operations on
> top of Cassandra, passing all of their test cases that don't use any
> out-of-the-way functions. Would it be possible to build something similar
> *solely* with CQL?
>
If it's doable on top of thrift, it's doable on top of CQL, yes. Note that
there
is use cases (and usegrid might well be one) for which the CQL version will
not
look much better than the thrift one would (typically, if you want to use
DynamicCompositeType, you will be back to manipulating your "cell" names and
values as blob client side, the very same way you'd do with thrift). Still,
it's
possible, and even when it's not prettier with CQL than it is with thrift
(and there
is a very large amount of use cases where it is prettier with CQL), it's
not worth
either.
> I'm fine with Thrift going away - I get the reasoning there. I just want to
> be able to hack against ("against", not "on") internals more easily.
>
Let's first maybe agree that this relatively separated from the "let's
freeze the
thrift API" proposal of Jonathan? If we do agree on that, maybe this should
be
discussed separately (at least some other thread), so it doesn't make it
sound
like this is some disagreement over Jonathan's proposal?
--
Sylvain
>
>
>
> On Thu, Mar 13, 2014 at 9:30 AM, Jonathan Ellis wrote:
>
> > You should probably give more details of those two data models for
> > those of us who have contributed neither to usergrid nor the mongodb
> > emulator. :)
> >
> > On Thu, Mar 13, 2014 at 9:10 AM, Nate McCall
> > wrote:
> > > After discussing this the past few days with a couple of folks, yes, I
> > > don't think maintaining the currently incubating Usergrid (
> > > https://usergrid.incubator.apache.org/) will be possible.
> > >
> > > Basically, how would you do what are essentially container collections
> of
> > > arbitrary runtime-definable UDTs? With everything in a virtual
> keyspace?
> > > Think about how we got the mongodb emulator working. Can you really do
> > this
> > > with CQL?
> > >
> > > Apigee is currently running several instances of this system at scale
> > for a
> > > number of very large clients. The main public cluster behind the
> > > AppServices product has "many tens of thousands" of tenants.
> > >
> > > Again, in all seriousness, is this dynamic a model possible via CQL?
> > >
> > > Granted, we may be an edge case at this point and maintaing a large
> chunk
> > > of code solely for that type of function is just bad software. Hence my
> > > desire to assist with
> > https://issues.apache.org/jira/browse/CASSANDRA-6846.
> >
> >
> >
> > --
> > Jonathan Ellis
> > Project Chair, Apache Cassandra
> > co-founder, http://www.datastax.com
> > @spyced
> >
>
>
>
> --
> -
> Nate McCall
> Austin, TX
> @zznate
>
> Co-Founder & Sr. Technical Consultant
> Apache Cassandra Consulting
> http://www.thelastpickle.com
>
Re: Proposal: freeze Thrift starting with 2.1.0
>
>
> > Essentially, Usergrid supports *all* of the basic mongo CRUD operations
> on
> > top of Cassandra, passing all of their test cases that don't use any
> > out-of-the-way functions. Would it be possible to build something similar
> > *solely* with CQL?
> >
>
> If it's doable on top of thrift, it's doable on top of CQL, yes. Note that
> there
> is use cases (and usegrid might well be one) for which the CQL version will
> not
> look much better than the thrift one would (typically, if you want to use
> DynamicCompositeType, you will be back to manipulating your "cell" names
> and
> values as blob client side, the very same way you'd do with thrift). Still,
> it's
> possible, and even when it's not prettier with CQL than it is with thrift
> (and there
> is a very large amount of use cases where it is prettier with CQL), it's
> not worth
> either.
>
This is exactly what I needed to know. Thank you - really.
I'll look into this and see if there is something I can write up as a
explanation/conversion example for folks in a similar situation.
>
>
> > I'm fine with Thrift going away - I get the reasoning there. I just want
> to
> > be able to hack against ("against", not "on") internals more easily.
> >
>
> Let's first maybe agree that this relatively separated from the "let's
> freeze the
> thrift API" proposal of Jonathan? If we do agree on that, maybe this should
> be
> discussed separately (at least some other thread), so it doesn't make it
> sound
> like this is some disagreement over Jonathan's proposal?
>
>
Fair enough.
+1 (non-binding).
--
-
Nate McCall
Austin, TX
@zznate
Co-Founder & Sr. Technical Consultant
Apache Cassandra Consulting
http://www.thelastpickle.com
