RE: API method signatures changing

That triggers another thought...

What terminology will you use in the book to describe the data model?  CQL?

When we wrote the RefCard on
DZone<http://refcardz.dzone.com/refcardz/apache-cassandra>,
we intentionally favored/used CQL terminology.  On advisement from Jonathan
and Kris Hahn, we wanted to start the process of sunsetting the legacy
terms (keyspace, column family, etc.) in favor of the more familiar CQL
terms (schema, table, etc.). I've gone on
record<http://css.dzone.com/articles/new-refcard-apache-cassandra>in
favor of the switch, but it is probably something worth noting in the
book since that terminology does not yet align with all the client APIs
yet. (e.g. Hector, Astyanax, etc.)

I'm not sure when the client APIs will catch up to the new terminology, but
we may want to inquire as to future proof the recipes as much as possible.

-brian




On Wed, Jun 27, 2012 at 4:18 PM, Edward Capriolo <edlinuxg...@gmail.com>wrote:

> On Wed, Jun 27, 2012 at 3:08 PM, Courtney Robinson <court...@crlog.info>
> wrote:
> > Sounds good.
> > One thing I'd like to see is more coverage on Cassandra Internals. Out of
> > the box Cassandra's great but having a little inside knowledge can be
> very
> > useful because it helps you design your applications to work with
> Cassandra;
> > rather than having to later make endless optimizations that could
> probably
> > have been avoided had you done your implementation slightly differently.
> >
> > Another thing that may be worth adding would be a recipe that showed an
> > approach to evaluating Cassandra for your organization/use case. I
> realize
> > that's going to vary on a case by case basis but one thing I've noticed
> is
> > that some people dive in without really thinking through whether
> Cassandra
> > is actually the right fit for what they're doing. It sort of becomes a
> > hammer for anything that looks like a nail.
> >
> > On Tue, Jun 26, 2012 at 10:25 PM, Edward Capriolo <edlinuxg...@gmail.com
> >
> > wrote:
> >>
> >> Hello all,
> >>
> >> It has not been very long since the first book was published but
> >> several things have been added to Cassandra and a few things have
> >> changed. I am putting together a list of changed content, for example
> >> features like the old per Column family memtable flush settings versus
> >> the new system with the global variable.
> >>
> >> My editors have given me the green light to grow the second edition
> >> from ~200 pages currently up to 300 pages! This gives us the ability
> >> to add more items/sections to the text.
> >>
> >> Some things were missing from the first edition such as Hector
> >> support. Nate has offered to help me in this area. Please feel contact
> >> me with any ideas and suggestions of recipes you would like to see in
> >> the book. Also get in touch if you want to write a recipe. Several
> >> people added content to the first edition and it would be great to see
> >> that type of participation again.
> >>
> >> Thank you,
> >> Edward
> >
> >
> >
> >
> > --
> > Courtney Robinson
> > court...@crlog.info
> > http://crlog.info
> > 07535691628 (No private #s)
> >
>
> Thanks for the comments. Yes the "INTERNALS" chapter was a bit tricky.
> The challenge of writing about internals is they go stale fairly
> quickly. I was considering writing a partitioner for the internals
> chapter but then I thought about it more:
> 1) Its hard
> 2) The APIs can change. (They work the same way across versions but
> they may have a different signature etc)
> 3) 99.99% of people should be using the random partitioner :)
>
> But I agree the external chapter can be made much stronger then it is.
>
> The recipe format strict. It naturally conflicts with the typical use
> case style. In a use case where you write a good amount of text
> talking about problem domain, previous solutions, bragging about
> company X. We can not do that with the recipe style, but we can do our
> best to make the recipes as real world as possible. I tried to do that
> throughout the text, you do not find many examples like 'writing foo
> records to bar column families'. However the format does not allow
> extensive text blocks mentioned above so it is difficult to set the
> stage for a complex and detailed real world problem. Still, I think
> for some examples we can take the next step and make the recipe more
> real world practical and more use-case like.
>



-- 
Brian ONeill
Lead Architect, Health Market Science (http://healthmarketscience.com)
mobile:215.588.6024
blog: http://weblogs.java.net/blog/boneill42/
blog: http://brianoneill.blogspot.com/

Reply via email to