+1, it's a good solution to both scenarios, with reduced overhead all
around.
On Nov 12, 2009, at 11:01 AM, Jonathan Ellis wrote:
works for me.
2009/11/12 Ted Zlatanov <[email protected]>:
On Thu, 12 Nov 2009 10:49:59 -0600 Jonathan Ellis
<[email protected]> wrote:
JE> On Thu, Nov 12, 2009 at 10:42 AM, Jonathan Mischo <[email protected]
> wrote:
Let's keep it simple. Forcing multiple connections from a purely
hypothetical use case is a no-brainer tradeoff. Connections are
not
expensive.
Even if we can do it sensibly? Connections aren't hugely
expensive, but
they're not free, either.
JE> I suppose, but if it requires sending a keyspace param w/ each
call,
JE> then it's not sensible. You waste far more overhead for that
in the
JE> common case -- serializing, deserializing, checking that it's
been
JE> authed -- than you gain from not having another connection in the
JE> uncommon one.
JE> I would be okay with being able to send a 2nd auth call to an
existing
JE> connection to switch the "current" keyspace, similar to how
rdbmses
JE> only have one active schema at a time.
How about:
login(Map<String, String> credentials) throws
CassandraAuthenticationSecurityException
setKeyspace(String keyspace) throws
CassandraAuthorizationSecurityException
and then all the existing API calls won't have a Keyspace parameter
as
previously discussed. This works for everyone, I think, and
separates
authentication from authorization nicely.
Ted
