On Fri, Nov 5, 2010 at 11:40 AM, Gary Dusbabek <gdusba...@gmail.com> wrote: >> >> I still think the query language is a good idea but I have one >> negative point about it. >> >> One of the selling point about a simple data model and access language >> was that there were never issues where a query planner "refused" to do >> the query the "optimal way" the user desired. For example a query >> using order and limit would first order the dataset and then limit >> when the user wanted to limit then order. > > This would be a limitation of the expressiveness of the grammar or a > failure on the part of the user and not really a problem with the > query planner. The QL statements so far are simple enough that there > is basically One Way to perform the operation once they are on the > server. I don't see ambiguity seeping in, but I suppose this is > possible. > >> Also without sounding syndical, I see SQL-ify catering to the lower >> half. Take projecting columns from a row for example. SQL-ish is going >> to encourage people to NOT learn about SlicePredicate and attempt get >> by using the SQL interface. They will not understand how to take >> advantage of the data model and what it provides. With 7.0 where >> schema changes can happen on the fly, users are going to have more >> freedom to create ColumnFamilies. Aided by their QL interface and >> their pre-disposition to think SQL they are going to structure column >> families like SQL tables. They could end up with unoptimized tables >> and planner making the non optimal queries. >> >> I somewhat feel a QL language would be like Cassandra training wheels. > > Valid concern, but a different debate. I think we've all seen the > effects of the "I did crap wrong, therefore Cassanda sucks" blog > posts. I hope that Cassandra's signal can make it to the point where > it is established enough to where those posts don't contribute as much > noise as they currently do. > > Looking out a year or so into the future, I think we'll be there. At > that point, features like a QL will help to make Cassandra more > approachable. But whether or not Cassandra should be more > approachable, I think, is a different debate. > > Gary. >
I believe it is the same debate. If a QL based API is made, will it really be able to replace the current API? Is the true target audience everyone. What do you think of the concept of not re-using sql keywords? Having a data access language a good idea but trying to make it look like SQL is counter intuitive to the data model and will leave people wondering what functions from SQL they have and do not have. Also having a subset SQL language can open you up to criticism. Mysql not supporting sub selects in older versions etc. With hive I do get some sneers about lack of IN support. What about a data access language that does not share and SQL keywords, custom made for NoSQL?
