On Jun 13, 2010, at Sun Jun 13, 9:34 PM, Benjamin Black wrote:
On Sun, Jun 13, 2010 at 5:58 PM, Matthew Conway m...@backupify.com wrote:
The ability to dynamically add new column families. Our app is currently
under heavy development, and we will be adding new column families at least
On Mon, Jun 14, 2010 at 7:27 AM, Matthew Conway m...@backupify.com wrote:
On Jun 13, 2010, at Sun Jun 13, 9:34 PM, Benjamin Black wrote:
On Sun, Jun 13, 2010 at 5:58 PM, Matthew Conway m...@backupify.com wrote:
The ability to dynamically add new column families. Our app is currently
under
On Jun 14, 2010, at Mon Jun 14, 10:45 AM, Jonathan Ellis wrote:
I already have automation, whats missing are the details of the exact steps
I need to automate to accomplish the schema modification on a live cluster.
Even the FAQ just points to the feature in 0.7 trunk.
Huh?
Not so much worried about temporary breakages, but more about design decisions
that are made to enhance cassandra at the cost of a data format change. So
long as the policy here is to preserve backwards compatibility with the on disk
storage format (possibly with an automatic conversion), even
What specifically is driving you to use trunk rather than the stable,
0.6 branch?
On Sun, Jun 13, 2010 at 1:37 PM, Matthew Conway m...@backupify.com wrote:
Not so much worried about temporary breakages, but more about design
decisions that are made to enhance cassandra at the cost of a data
The ability to dynamically add new column families. Our app is currently under
heavy development, and we will be adding new column families at least once a
week after we have shipped the initial production app. From the existing docs,
it seemed to me that the procedure for changing schema in
