Thanks a lot for these suggestions.
My fat client issues came mainly from the fact that the Wiki example (
http://wiki.apache.org/cassandra/ClientExamples) just doesn't work with
0.6.0beta3.
- StorageService.instance()
does not work because instance is a static variable, not a method
- new ColumnPatch("Standard1", null, ("colb").getBytes())
does not work because there is no such constructor signature defined;
use
new ColumnPath("Standard1").setColumn("colb".getBytes())
instead
- StorageProxy.insert(change)
does not work, because there is no such method (static or dynamic) in
this
class, I started to look around and came up with something like
List<RowMutation> ml = new Stack<RowMutation>();
ml.add(change);
StorageProxy.mutate(ml);
but it doesn't quite work out until now (however, also doesn't throw
an exception).
Please don't shoot me, I came up with this code just grep'ing the
source and doing something that seemed to make a little sense... ;-)
Greetings,
Roland
2010/3/24 Eric Evans <eev...@rackspace.com>
> On Wed, 2010-03-24 at 14:15 +0100, Roland Hänel wrote:
> > Still, I'm somewhat confused which API to choose if I was heading for
> > a
> > bigger project
> >
> > 1. plain Thrift (for Java)?
> > Seems the major advantage is that Thrift is available in many
> > languages, but
> > if I'm only interested in Java that doesn't give me much. The Java
> > code on
> > the native Thrift interface looks quite awful. It also seems to me as
> > if it
> > would result in many lines of code even for quite trivial jobs.
>
> Right, using raw Thrift means that you're interacting with the system by
> calling the RPC methods directly. You've got maximum flexibility but
> you're quickly going to notice a lot of boiler plate accumulating.
>
> > 2. a higher level Java Client?
> > I didn't look at Hector right now, however it confused me somewhat
> > that if
> > something like Hector was the "best choice", why isn't this then
> > bundled
> > with Cassandra?
>
> The "best choice" is always going to be subjective, but Hector has
> developed a lot of momentum in a short period of time. It would not be
> at all unreasonable to call it the de facto Java library for Cassandra.
>
> As for why it's not bundled, that is a feature and not a bug. As
> separate projects the two can move at their own pace, use the work-flow
> of their own choosing, pick the tools right for them, and add committers
> without the unwanted additional oversight.
>
> IMO, bundling Hector wouldn't enhance it's development, (if anything, it
> would inhibit it), and by sending the message that it was the One True
> Library it would unnecessarily close the door on competition.
>
> > 3. the "native Java fat Client"
> > I started some experiments with it, however couldn't get it completely
> > working, documentation in the Wiki is not really usuable at all.
> > Question
> > would be if this is something that you (the developers) consider as
> > the "big
> > thing for the future" or is this some niche for lets say high
> > performance
> > bulk jobs but not for the "everyday Java client program"?
>
> The fat client is different from Thrift in that it obtains a sort of
> limited membership in the cluster and is able to route requests directly
> to nodes, as opposed to the proxying that can occur when you make a
> Thrift call to a random node.
>
> The fat client is not as well tested, and it's true that we usually
> steer people toward Thrift unless they have specific requirements. If
> you're having problems though, we'd love to hear about them, either
> here, or in a bug report
> (https://issues.apache.org/jira/browse/CASSANDRA).
>
>
> --
> Eric Evans
> eev...@rackspace.com
>
>
