No. I know of none. I will however, make sure the the abstract keyword is added to the classes you have mentioned.
On Aug 29, 2011, at 2:17 AM, Vivek Mishra wrote: > 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
