> are you really recommending I throw 4 years of work out and completely
rewrite code that works and has been tested?
Our codebase was about 3 years old, and we finished migrating it to CQL not
that long ago. It can definitely be frustrating to have to touch stable
code to modernize it. Our desi
> Where we differ that I feel the coverage for existing thrift use cases
isn't
> 100%. That may be right or wrong, but it is my impression.
Here's my problem: either CQL covers all existing thrift use cases or it
does
not (in which case the non supported use case should be pointed out). It's a
tec
@jack thanks for taking time to respond. I agree I could totally redesign
and rewrite it to fit in the newer CQL3 model, but are you really
recommending I throw 4 years of work out and completely rewrite code that
works and has been tested?
Ignoring the practical aspects for now and exploring the
Peter,
At least from your description, the proposed use of the clustering column
name seems at first blush to fully fit the bill. The point is not that the
resulting clustered primary key is used to reference an object, but that a
SELECT on the partition key references the entire object, which wil
I've written my fair share of crappy code, which became legacy. then I or
someone else was left with supporting it and something newer. Isn't that
the nature of software development.
I forget who said this quote first, but I'm gonna borrow it "only pretty
code is code that is in your head. once it
On Wed, Jan 21, 2015 at 2:09 PM, Peter Lin wrote:
> on the topic of multiple incompatible API's I recommend you look at
> SqlServer and Sybase. Most of the legacy RDBMS have multiple incompatible
> API. Though in some cases, it is/was unavoidable.
>
My bet is that the small development team resp
everyone is different. I also recommend users take time to understanding
every tool they use as much as time allows. We don't always have the luxury
of time, but I see no point recommending laziness.
I'm probably insane, since I also spend time reading papers on CRDT, paxos,
query compilers, machi
I apologize if I've offended you, but I clearly stated CQL3 supports
dynamic columns. How it supports dynamic columns is different. If I'm
reading you correctly, I believe we agree both thrift and CQL3 support
dynamic columns. Where we differ that I feel the coverage for existing
thrift use cases i
On Wed, Jan 21, 2015 at 9:19 AM, Peter Lin wrote:
>
> I consistently recommend new users learn and understand both Thrift and
> CQL.
>
FWIW, I consider this a disservice to new users. New users should use CQL,
and not deploy against a deprecated-in-all-but-name API. Understanding
non-CQL *storag
On Wed, Jan 21, 2015 at 6:19 PM, Peter Lin wrote:
> the dynamic column can't be part of the primary key. The temporal entity
> key can be the default UUID or the user can choose the field in their
> object. Within our framework, we have concept of temporal links between one
> or more temporal ent
the example you provided does not work for for my use case.
CREATE TABLE t (
key blob,
static my_static_column_1 int,
static my_static_column_2 float,
static my_static_column_3 blob,
,
dynamic_column_name blob,
dynamic_column_value blob,
PRIMARY KEY (key, dyna
On Wed, Jan 21, 2015 at 4:44 PM, Peter Lin wrote:
> I don't remember other people's examples in detail due to my shitty
> memory, so I'd rather not misquote.
>
Fair enough, but maybe you shouldn't use "people's examples you don't
remenber" as argument then. Those examples might be wrong or outda
I don't remember other people's examples in detail due to my shitty memory,
so I'd rather not misquote.
In my case, I mix static and dynamic columns in a single column family with
primitives and objects. The objects are temporal object graphs with a known
type. Doing this type of stuff is basicall
> I've chatted with several long time users of Cassandra and there's things
> CQL3 doesn't support.
>
Would you care to elaborate then? Maybe a simple example of something (or
multiple things since you used plural) in thrift that cannot be supported
in CQL?
And please note that I'm *not* saying th
I've studied the source code and I don't believe that statement is true.
I've chatted with several long time users of Cassandra and there's things
CQL3 doesn't support.
Like I've said before. Thrift and CQL3 compliment each other. I totally
understand some committers don't want the overhead due to
On Wed, Jan 21, 2015 at 3:46 AM, Peter Lin wrote:
>
> I don't understand why people [...] pretend it supports 100% of the use
> cases.
>
Have you consider the possibly that it's actually true and you're just
wrong by lack of knowledge?
--
Sylvain
Hello,
Peter highlighted the tradeoff between Thrift and CQL3 nicely in this
case, i.e. requiring a different design approach for this solution.
Collections do not sound like a good fit for your current challenge, but is
there a different way to design/solve your challenge using CQL techniques?
the thing is, CQL only handles some types of dynamic column use cases.
There's plenty of examples on datastax.com that shows how to do CQL style
dynamic columns.
based on what was described by Chetan, I don't feel CQL3 is a perfect fit
for what he wants to do. To use CQL3, he'd have to change his
18 matches
Mail list logo
