Sorry, I am not your team. But I do care native api. A native api has much more impacts than anybody expected. Few reasons list here, 1. Using native api can help understand Cassandra DB much deeper. 2. Native api can support unusual customer with special needs. In some cases, basic and high performance requires few api calls and less code, native code provide this possible. I have a embed system with Oracle native C api code still use today. 3. Earlier Cassandra adaptors will hate to move to CQL even it "looks" better and "seems" beauty, but it requires major code changes. 4. Without native api will lost potential support other drivers, who knows, somebody may implement other QL, or may be JDBC extends feature to support Cassandra. 5. Without native api, Cassandra has pressure to develop a standard driver for each language as Edward Capriolo perceived
I believe Cassandra should have low level native api regardless CQL or anything new QLs in the future. This will save earlier customer's investments and give Cassandra a much broad future. CQL looks nice today, doesn't means good for tomorrow. Regards, Zhong Li On Mar 11, 2014, at 4:43 PM, Jonathan Ellis wrote: > Nobody can seriously use or develop against Cassandra with only the > raw Thrift generated code either, so I agree that this is really a > different discussion. > > On Tue, Mar 11, 2014 at 3:38 PM, Edward Capriolo <edlinuxg...@gmail.com> > wrote: >> "I am confused how any of this is relevant to Jonathan's original email." >> >> Here is how: >> >> I believe if native is the new official transport, Cassandra should include >> the Java driver source code with the project. >> >> Without the driver code inside the project how can someone use/develop the >> software. >> >> >> On Tue, Mar 11, 2014 at 4:24 PM, Brandon Williams <dri...@gmail.com> wrote: >> >>> I am confused how any of this is relevant to Jonathan's original email. >>> >>> >>> On Tue, Mar 11, 2014 at 3:13 PM, Edward Capriolo <edlinuxg...@gmail.com >>>> wrote: >>> >>>> "How about the myriad of thrift wrappers that aren't in-tree either?" >>>> >>>> How about all the times we trashed hbase saying "hbase treats non java >>>> people like second class citizens" >>>> >>>> >>>> >>> http://mail-archives.apache.org/mod_mbox/hbase-user/201108.mbox/%3ccafk14gsrnysj_oev2_utwc-+u4ssdmdsmp2dgrst90hoypw...@mail.gmail.com%3E >>>> >>>> Nice to see us pulling a total 180. >>>> >>>> >>>> On Tue, Mar 11, 2014 at 4:09 PM, Brandon Williams <dri...@gmail.com> >>>> wrote: >>>> >>>>> How about the myriad of thrift wrappers that aren't in-tree either? >>>>> >>>>> >>>>> On Tue, Mar 11, 2014 at 3:03 PM, Edward Capriolo < >>> edlinuxg...@gmail.com >>>>>> wrote: >>>>> >>>>>> "Other databases treat this issue differently, and there are a set of >>>>>> tradeoffs. Mysql's decision may not be the best for Cassandra." >>>>>> >>>>>> Do you know of any other database that does not provide it's own >>>> driver? >>>>>> >>>>>> >>>>>> On Tue, Mar 11, 2014 at 3:55 PM, Tyler Hobbs <ty...@datastax.com> >>>> wrote: >>>>>> >>>>>>> On Tue, Mar 11, 2014 at 2:24 PM, Edward Capriolo < >>>>> edlinuxg...@gmail.com >>>>>>>> wrote: >>>>>>> >>>>>>>> "The native protocol spec is the source of truth. If Cassandra's >>>>>>> behavior >>>>>>>> doesn't match the spec, it's a bug. Likewise for any drivers. >>> I'm >>>>> not >>>>>>>> sure how this makes it unclear whether a bug is server-side or >>>>>>>> client-side. Maybe an example scenario would be useful?" >>>>>>>> >>>>>>>> In the near future. I am a cassadra committer. I find a bug >>> between >>>>>>>> cassanda server and java client driver. For example, the server >>> is >>>>>>> sending >>>>>>>> an unsigned by the other is expecting a signed byte. >>>>>>>> >>>>>>>> As a cassandra committer I can only change half of the equation. >>> I >>>>>> change >>>>>>>> the cassandra server, that would break the ruby-client. That >>> won't >>>>> work >>>>>>>> will it? >>>>>>>> >>>>>>>> My only recourse as a cassandra committer is to go ask some other >>>>>> entity >>>>>>> to >>>>>>>> change their driver. >>>>>>>> >>>>>>> >>>>>>> The solution would be: >>>>>>> 1. Update the spec (for the current protocol version) to specify >>> that >>>>>> it's >>>>>>> an unsigned byte. (Perhaps add a note that this will change in the >>>>> next >>>>>>> protocol version.) >>>>>>> 2. In the next version of the protocol, specify that the byte is >>>> signed >>>>>> and >>>>>>> change Cassandra's behavior to match this. Note this change in >>> the >>>>>>> "changes" section of the spec. >>>>>>> >>>>>>> This doesn't break existing clients and it allows the behavior to >>> be >>>>>> fixed >>>>>>> with the next protocol version. (Cassandra also supports multiple >>>>>> versions >>>>>>> of the native protocol, fwiw.) >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> "This means the spec is ambiguous. In that case, I imagine the >>>>> proper >>>>>>>> solution would be to create a jira ticket and decide how to >>> resolve >>>>> the >>>>>>>> ambiguity in the spec." >>>>>>>> >>>>>>>> Yes but then after you change the spec, one client is broken and >>>> one >>>>> is >>>>>>>> not. Is one client more "official" then another? Do you change >>> the >>>>> spec >>>>>>> to >>>>>>>> match the client with "more users". >>>>>>>> >>>>>>> >>>>>>> You change the spec to match whatever Cassandra is doing. It's >>> not a >>>>>>> matter of what driver is more popular. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Think about mysql. Does it ship with a driver? Yes. Who writes >>> the >>>>>>> driver? >>>>>>>> mysql. Where is the source code for this driver? Inside the same >>>>>>> repository >>>>>>>> as the server. Cassandra should be the same way. >>>>>>> >>>>>>> >>>>>>> Other databases treat this issue differently, and there are a set >>> of >>>>>>> tradeoffs. Mysql's decision may not be the best for Cassandra. >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Tyler Hobbs >>>>>>> DataStax <http://datastax.com/> >>>>>>> >>>>>> >>>>> >>>> >>> > > > > -- > Jonathan Ellis > Project Chair, Apache Cassandra > co-founder, http://www.datastax.com > @spyced
