Stateful Thrift/Avro API in 0.7 (set_keyspace)

[Thomas Heller <in...@zilence.net>]

Hey,

I wonder if there is any particular reasoning why the API
(thrift/avro) will become stateful in 0.7? Granted it already is doing
that for "login", but why is the keyspace argument moved to a stateful
level?

I wrote a ruby client to help me in my app development and while it
currently just connects to one keyspace, I was planning to divide my
data into several keyspaces since there are some parts of data where I
want a higher RF and some where a low RF is just fine.

In preparation for 0.7 I'd now refactor parts of my client to support
stateful keyspace selection but I just wondered why this "stateful"
path was chosen? Will set_keyspace() be an expensive operation?

Cheers,
/thomas

PS:
For the curious, my Client is available at:

http://github.com/thheller/greek_architect

While fully functional I doubt it would be very useful too anyone else
at this time.

Re: Stateful Thrift/Avro API in 0.7 (set_keyspace)

[Thomas Heller <in...@zilence.net>]

On Tue, Jul 6, 2010 at 6:00 PM, Jonathan Ellis <jb...@gmail.com> wrote:
> Because stateful keyspace is semantically closer to how people use it:

Hmm no other reason?

Writing a client-side wrapper which turns

get(key, column_path, clevel) into
get(@keyspace, key, column_path, clevel)

is trivial in pretty much any language.

Well, looked at the code and switching isnt gonna be expensive so my
concern is answered.

Since set_keyspace resets login it might be "useful" to combine those
two? set_keyspace(string, optional:auth)?

Cheers,
/thomas

Re: Stateful Thrift/Avro API in 0.7 (set_keyspace)

[Jonathan Ellis <jb...@gmail.com>]

Because stateful keyspace is semantically closer to how people use it:
one keyspace per application.

If Thrift allowed us to make the keyspace-per-method-call optional we
could go that route, but it does not.

On Tue, Jul 6, 2010 at 10:56 AM, Thomas Heller <in...@zilence.net> wrote:
> Hey,
>
> I wonder if there is any particular reasoning why the API
> (thrift/avro) will become stateful in 0.7? Granted it already is doing
> that for "login", but why is the keyspace argument moved to a stateful
> level?
>
> I wrote a ruby client to help me in my app development and while it
> currently just connects to one keyspace, I was planning to divide my
> data into several keyspaces since there are some parts of data where I
> want a higher RF and some where a low RF is just fine.
>
> In preparation for 0.7 I'd now refactor parts of my client to support
> stateful keyspace selection but I just wondered why this "stateful"
> path was chosen? Will set_keyspace() be an expensive operation?
>
> Cheers,
> /thomas
>
> PS:
> For the curious, my Client is available at:
>
> http://github.com/thheller/greek_architect
>
> While fully functional I doubt it would be very useful too anyone else
> at this time.
>



-- 
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of Riptano, the source for professional Cassandra support
http://riptano.com