incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vivek Mishra <>
Subject Re: CqlResult in CassandraConnection
Date Mon, 29 Aug 2011 06:17:40 GMT
Thanks Rick.

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

<Vivek> As we have got 1 super class and sub class in place for ( AbstractCassandraConnection,AbstractResultSet
and AbstractStatement). So thought to ask for if any other implementation is on roadmap? </vivek>


From: Rick Shaw <>
To:; Vivek Mishra <>
Sent: Monday, August 29, 2011 12:59 AM
Subject: Re: CqlResult in CassandraConnection

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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message