Should we just remove that from the wiki, seeing as how we have the same (?) sample in contrib/ where it is more likely to be kept up to date?
2010/3/24 Roland Hänel <rol...@haenel.me>: > 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 >> > >
