On Fri, 29 Oct 2010 10:07:43 -0500 (CDT) "Stu Hood" <stu.h...@rackspace.com> wrote:
SH> Most reasonable languages these days have a way to define what looks SH> like a DSL: giving people a text DSL which is subject to injection SH> attacks and can't be type checked without support from a client SH> driver anyway is brain dead. I don't think SQL-like query languages are DSLs in the classic sense. Injection attacks are a red herring: they are a client issue, not a library or a server problem. Type checking is a valid complaint and I think it's balanced out by the flexibility of a text protocol. SH> Regarding performance: assuming optimized RPC libraries (which we do SH> not yet have in Avro, and which Thrift is getting better at), SH> serializing to a string and back will never be as performant as SH> using a pre-parsed representation of the statement on both SH> sides. "Oh but we can add prepared statements!" Poppycock. Consider that Cassandra's statements will never be as complicated as a regular RDBMS, so parsing them efficiently is not so hard. The parameters can be attached to the query, not necessarily inlined. A native JDBC level 4 driver could be a very efficient answer to this problem, too. SH> The stated problem is that backwards compatibility is hard to SH> provide: if that is the core complaint, then changing to a text SH> based serialization format with a sexy name in order to add SH> backwards compatibility is a severe overreaction to the SH> problem. Instead, I would propose evolving the API in a manner that SH> simplifies it. I think it would be great to allow multiple APIs in Cassandra (when I proposed it in the past, it was not allowed, and AFAIK still isn't beyond Avro and Thrift). Then this wouldn't be an yes-or-no choice and the Thrift API would still be available to those who need it. Ted
