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> Vivek ________________________________ From: Rick Shaw <wfs...@gmail.com> To: dev@cassandra.apache.org; Vivek Mishra <vivek.mis...@yahoo.com> 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 <wfs...@gmail.com> > To: dev@cassandra.apache.org > Cc: Vivek Mishra <vivek.mis...@yahoo.com> > 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 <vivek.mis...@yahoo.com> 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 | http://www.acunu.com | @acunu
