On Thu, 12 Nov 2009 10:59:52 -0600 Ted Zlatanov <[email protected]> wrote:
TZ> 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. TZ> How about: TZ> login(Map<String, String> credentials) throws CassandraAuthenticationSecurityException TZ> setKeyspace(String keyspace) throws CassandraAuthorizationSecurityException TZ> and then all the existing API calls won't have a Keyspace parameter as TZ> previously discussed. This works for everyone, I think, and separates TZ> authentication from authorization nicely. I created an issue: https://issues.apache.org/jira/browse/CASSANDRA-547 and will post updates there as needed. This is stage 1, meaning this is the 0.5 work that will keep the old API. Stage 2 will remove the Keyspace parameters from the API so I'll put that work in a different issue, linked to CASSANDRA-547. Thanks Ted
