cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CASSANDRA-79) Multi-table support
Date Tue, 19 May 2009 02:42:45 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12710589#action_12710589
] 

Jonathan Ellis commented on CASSANDRA-79:
-----------------------------------------

>From what I have seen the underlying mechanics for multiple table support are already
there.  We just need to make all the places that assume there is only one for convenience,
stop doing so.

DatabaseDescriptor parses and stores the results of the config xml.  Right now the shortcut
for "get the table name" is DD.getTables().get(0).  I suggest auditing the calls to getTables()
and see if any are actually using it for more than that.  (I don't think there are.)  Then
get rid of it so nobody is tempted to do that anymore and start fixing them.

There are two classes of fixes.  Client API fixes and internal uses.  The client ones are
probably easier in general.  What should happen is, the client gives cassandra a table name
as part of any API call, and that is passed to one of the handler methods (e.g., ReadVerbHandler,
RowMutationVerbHandler).  Those will have the table name as part of the Command object they
read off the wire.  So just start including the table name down the call stack.

The internal ones are a bit harder but only a little.  Often an object will need the table
name in a place where its caller does not know the table either, e.g. ColumnFamily.getColumnComparator.
 Here you'll need to add an instance variable containing either the table name or a reference
to the parent Table object.  Adding factory methods  to Table such as Table.getColumnFamily
may be convenient.

Some of DatabaseDescriptor itself needs to stop assuming only one table.  This will not be
much code.  applicationColumnFamilies_ is one place.  at the very least that needs another
layer of Map<tablename, appCFs> like tableToCFMetaDataMap_ does.  If you're more ambitious
you could try moving those into the Table object as additional cleanup.

Please leave any questions here in case anyone else wants to help. :)

> Multi-table support
> -------------------
>
>                 Key: CASSANDRA-79
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-79
>             Project: Cassandra
>          Issue Type: New Feature
>    Affects Versions: trunk
>            Reporter: Jonathan Ellis
>             Fix For: 0.4
>
>
> Cassandra has preliminary support for multiple tables (namespaces / sets of ColumnFamilies)
but a lot of the code assumes there is only one.  Multitable support is important for allowing
multiple applications to run on a single cluster.  It's also useful to cleanly separate "system"
columnfamilies from application data.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message