incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Shaw <>
Subject Re: CqlResult in CassandraConnection
Date Sun, 28 Aug 2011 19:29:13 GMT
The reason they are set up that was is to clearly delineate between methods that there are
no plans to implement any time in the near future; it minimizes the distraction in the classes
that get a lot of activity. It is not necessary, but it was done that way when I started looking
at the code and I recognized it as a clever approach and I followed its example. As to being
confusing, I guess the abstract keyword was inadvertently omitted along the way and got propagated;
but the intended effect is not hampered by the omission. I'll clean it up with the addition
of the keyword to improve on its clarity.

As to class level hierarchy, I am not sure I understand the reference? Could you elaborate?

As to plans: Broad plans for 1.0 timeframe target are published in CASSANDRA-2876. The implementation
of the prepared statement improvements (CASSANDRA-2885) is waiting on required support of
CQL in various forms. 

I am also unclear as to what you are asking for in the final paragraph? Changes in each of
those classes is inevitable to support new features but there are no plans (by me) for any
other  (alternate) classes. Perhaps you are implying they could be marked final? Note CassandraPreparedStatement
is a sub-class of CassandraStatement.

On Aug 28, 2011, at 1:33 PM, Vivek Mishra wrote:

> I was looking at AbstractCassandraConnection,AbstractResultSet and AbstractStatement
classes. Name looks to me quite confusing as none of them is an abstract class.  1 more thin,
any specific reason for creating class level hierarchy? 
> -2876
> Plans for any other implementation/s of CassandraConnection, ResultSet and Statement
sub class?
> Vovel
> ________________________________
> From: Rick Shaw <>
> To:
> Cc: Vivek Mishra <>
> Sent: Sunday, August 28, 2011 9:39 PM
> Subject: Re: CqlResult in CassandraConnection
> The class itself is not public, so it is generally protected from misuse, but it is a
good recommendation to remove the public modifier on those non-interface imethods as well.
I'll see to it.
> On Aug 28, 2011, at 11:35 AM, Eric Evans wrote:
>> On Sun, Aug 28, 2011 at 3:47 AM, Vivek Mishra <> wrote:
>>> Recently i can see changes made in jdbc connection API.
>>> Wondering why are we returning CqlResult from CassandraConnection, ideally it
should return ResultSet as jdbc api.
>>> Any thoughts?
>> The execute methods aren't a part of the java.sql.Connection
>> interface, but they are public, and so shouldn't be returning Thrift
>> structs.  Maybe we just need to drop the public modifier.
>> Can you open a ticket Vivek?
>> -- 
>> Eric Evans
>> Acunu | | @acunu

View raw message