Jonathan Ellis
Fri, 26 Feb 2010 12:40:44 -0800
Remember that the header is per-segment. So I would just say that CF modification forces a new segment creation.
We can support additions and deletions just by doing that, so that should probably be the first milestone. Renames are harder because currently we map id -> name -> files on disk. We'd need to change that to id -> files on disk, id -> sequence of names and when they were in effect for HH. (Maybe this is the straw that breaks the HH camel's back?) -Jonathan On Fri, Feb 26, 2010 at 11:22 AM, Gary Dusbabek <gdusba...@gmail.com> wrote: > The commit log currently has a header section whose size is constant, > but is a function of the total number of defined column families. > This isn't going to work with CASSANDRA-44 where CFs can be added or > removed on the fly. I see two options: > > 1. hard code the size of the header to accommodate a maximum number > of CFs. I don't like this approach because it imposes a hard limit. > 2. move the header into its own file. I don't like this because it > adds complexity. > > Any better other ideas? > > Some background: the data stored in the header indicates a) which CFs > are 'dirty' and b) log replay offsets for each CF. >