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
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 th
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 featu
On Tue, Dec 23, 2014 at 10:26 AM, Peter Lin 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 tha
@Eric - totally agree. People should choose what is most comfortable for
them, but they should also take time to learn both and really understand
Cassandra at a deep level. Same is true of any database, even if most
people don't bother to read and understand how a piece of technology works.
I've s
As Ryan mentioned, CQL is simply a translation layer to the underlying
storage mechanism you're already familiar with with Thrift.
There are definitely corner cases where it's not possible to get a
one-for-one equivalent in CQL vs Thrift, and even when there's equivalents,
the underlying data migh
basically any time you want to store maps of maps, lists of lists or actual
java objects, CQL is not a good fit. CQL is really only good for primitive
types, flat lists, maps and sets.
Using Cassandra pure with static columns is perfectly valid, but I don't
live in that world. Most of what I do re
Ryan,
Can you elaborate a little on "Thrift over CQL is modeling clustering
columns in different nesting between rows is trivial in Thrift and not
really doable in CQL"?
On Dec 24, 2014 8:30 AM, "Ryan Svihla" wrote:
> I'm not entirely certain how you can't model that to solve your use case
> (wo
I've listed several in the past, I won't bother repeating it again.
Just search the mailing list
Sent from my iPhone
> On Dec 24, 2014, at 8:30 AM, Ryan Svihla wrote:
>
> Peter,
>
> Can you come up with some specifics? I'm always interested in finding more
> corner cases, but it's also pos
Peter,
Can you come up with some specifics? I'm always interested in finding more
corner cases, but it's also possible I have a modeling alternative that you
may not have considered yet, regardless it's good practice and background
for me.
On Tue, Dec 23, 2014 at 12:26 PM, Peter Lin wrote:
>
>
I'm not entirely certain how you can't model that to solve your use case
(wouldn't you be filtering the events as well, and therefore be able to get
all that in one query).
What you describe there has a number of avenues (collections, just heavier
use of statics in a different order than you spec
I'm bias in favor of using both thrift and CQL3, though many people on the
list probably think I'm crazy.
CQL3 is good if what you need fits nicely in static columns, but it doesn't
if you want to use dynamic columns and/or mix & match both in the same
columnFamily. For a lot of what I use Cassand
Thanks, Ryan. I wasn't aware of static column support, and indeed they get
me most of what I need. I think the only potential inefficiency is still
at query time. Using Thrift, I could design the column family to get the
all the static and dynamic content in a single query.
If event_source and
Don't static columns get you what you want?
http://www.datastax.com/documentation/cql/3.1/cql/cql_reference/refStaticCol.html
On Dec 22, 2014 10:50 PM, "David Broyles" wrote:
> Although I used Cassandra 1.0.X extensively, I'm new to CQL3. Pages such
> as http://wiki.apache.org/cassandra/Client
Although I used Cassandra 1.0.X extensively, I'm new to CQL3. Pages such
as http://wiki.apache.org/cassandra/ClientOptionsThrift suggest new
projects should use CQL3.
I'm wondering, however, if there are certain use cases not well covered by
CQL3. Consider the standard timeseries example:
CREAT
15 matches
Mail list logo