The kind of query language I'm thinking of is closer to Datalog, which is what Datomic uses. It's a personal bias, but I find it easier and cleaner to express joins, subqueries and correlated subqueries in a LISP-like/datalog like syntax than SQL.
Since CQL is modeled/inspired by SQL, it inherits the same limitations in syntax and expressiveness. For simple single table queries SQL is easier and most people are familiar with it. For expressing multi-dimensional queries on data that uses star/snowflake schema, SQL isn't a good fit. There's plenty of literature on this topic, so I'm not alone in this. When we get into things like temporal queries and temporal query languages, some major changes to CQL would be needed. My guess, the changes would be significant enough that sticking with CQL syntax starts to be counter productive. Anyone that has used or built bi-temporal databases knows this first hand. For more than 2 decades many people put up with using SQL for temporal queries, but it sucks. There's no nice way to put it. a popular use case for Cassandra is time series data. Basically people are using it as a simple temporal database of sorts. Once you take a step back and look at the existing research on temporal databases/active databases, it becomes quite clear all of us have been forced to use a language that isn't well suited for temporal databases. Just look at all the different ways people use Cassandra to store time series data. peter On Mon, Dec 29, 2014 at 6:45 PM, Eric Stevens <migh...@gmail.com> wrote: > So while not exactly the same, this seems like a good analogy for > suggesting a third interface to fix problems with existing interfaces: > http://xkcd.com/927/ > > Even if the CQL parsing code in Cassandra is subpar (I haven't studied > it), that's not an especially compelling case to suggest replacing the > query language itself. It seems like the sort of thing that could be fixed > in a perfectly compatible and transparent way at the point when it starts > to introduce problems. In fact, a major upside to CQL is that it puts less > of the work on the client, making it easier to address problems, introduce > new features, and deprecate old ones over a fixed interface like Thrift > which requires all client libs to keep up to date for the adoption of any > new features. > > The limitations of CQL come more from the underlying storage engine > limitations, and the query interface won't change those. I was resistant > to CQL at first as well. Having used it for a while, I'm honestly glad to > put Thrift behind me (6 months ago I probably wouldn't have had the same > opinion). The more I use it, the more I have come to like it. > > I started as a skeptic, and became a convert. > > On Mon, Dec 29, 2014 at 12:04 PM, Peter Lin <wool...@gmail.com> wrote: > >> >> In my bias opinion something else should replace CQL and it needs a >> proper rewrite on the sever side. >> >> I've studied the code and having written query parsers and planners, what >> is there today isn't going to work long term. >> >> Whatever replaced both thrift and CQL needs to provide 100% of the >> features that exist today >> >> Sent from my iPhone >> >> On Dec 29, 2014, at 1:34 PM, Robert Coli <rc...@eventbrite.com> wrote: >> >> On Tue, Dec 23, 2014 at 10:26 AM, Peter Lin <wool...@gmail.com> wrote: >> >>> >>> I'm bias in favor of using both thrift and CQL3, though many people on >>> the list probably think I'm crazy. >>> >> >> I don't think you're "crazy" but I do think you will ultimately face the >> deprecation of thrift. >> >> Briefly, I disbelieve the idea that Cassandra can or would or should keep >> two incompatible, non-pluggable APIs. I therefore assert that the Apache >> Cassandra team will not likely do this unreasonable thing, and thrift will >> eventually be removed. >> >> I strongly anti-recommend new uses of thrift/"legacy tables" for this >> reason. >> >> =Rob >> >> >
