This release requires either Python 2.6 or 2.7. Python 2.4 and 2.5 are no longer supported. There are no concrete plans for Python 3 compatibility yet.
This release fixes a minor bug and upgrades the bundled Cassandra Thrift client interface to 19.34.0, matching Cassandra 1.2.0-beta1. This doesn’t affect any existing Thrift methods, only adds new ones (that aren’t yet utilized by pycassa), so there should not be any breakage.
This release has few changes, and should make for a smooth upgrade from 1.7.0.
This release has a few relatively large changes in it: a new connection pool stats collector, compatibility with Cassandra 0.7 through 1.1, and a change in timezone behavior for datetimes.
Before upgrading, take special care to make sure datetimes that you pass to pycassa (for TimeUUIDType or DateType data) are in UTC, and make sure your code expects to get UTC datetimes back in return.
Likewise, the SystemManager changes should be backwards compatible, but there may be minor differences, mostly in create_column_family() and alter_column_family(). Be sure to test any code that works programmatically with these.
All datetime objects create by pycassa now use UTC as their timezone rather than the local timezone. Likewise, naive datetime objects that are passed to pycassa are now assumed to be in UTC time, but tz_info is respected if set.
Specifically, the types of data that you may need to make adjustments for when upgrading are TimeUUIDType and DateType (including OldPycassaDateType and IntermediateDateType).
This release adds a few minor features and several important bug fixes.
The most important change to take note of if you are using composite comparators is the change to the default inclusive/exclusive behavior for slice ends.
Other than that, this should be a smooth upgrade from 1.5.x.
This release only affects those of you using DateType data, which has been supported since pycassa 1.2.0. If you are using DateType, it is very important that you read this closely.
DateType data is internally stored as an 8 byte integer timestamp. Since version 1.2.0 of pycassa, the timestamp stored has counted the number of microseconds since the unix epoch. The actual format that Cassandra standardizes on is milliseconds since the epoch.
If you are only using pycassa, you probably won’t have noticed any problems with this. However, if you try to use cassandra-cli, sstable2json, Hector, or any other client that supports DateType, DateType data written by pycassa will appear to be far in the future. Similarly, DateType data written by other clients will appear to be in the past when loaded by pycassa.
This release changes the default DateType behavior to comply with the standard, millisecond-based format. If you use DateType, and you upgrade to this release without making any modifications, you will have problems. Unfortunately, this is a bit of a tricky situation to resolve, but the appropriate actions to take are detailed below.
To temporarily continue using the old behavior, a new class has been created: pycassa.types.OldPycassaDateType. This will read and write DateType data exactly the same as pycassa 1.2.0 to 1.5.0 did.
If you want to convert your data to the new format, the other new class, pycassa.types.IntermediateDateType, may be useful. It can read either the new or old format correctly (unless you have used dates close to 1970 with the new format) and will write only the new format. The best case for using this is if you have DateType validated columns that don’t have a secondary index on them.
To tell pycassa to use OldPycassaDateType or IntermediateDateType, use the ColumnFamily attributes that control types: column_name_class, key_validation_class, column_validators, and so on. Here’s an example:
from pycassa.types import OldPycassaDateType, IntermediateDateType
from pycassa.column_family import ColumnFamily
from pycassa.pool import ConnectionPool
pool = ConnectionPool('MyKeyspace', ['192.168.1.1'])
# Our tweet timeline has a comparator_type of DateType
tweet_timeline_cf = ColumnFamily(pool, 'tweets')
tweet_timeline_cf.column_name_class = OldPycassaDateType()
# Our tweet timeline has a comparator_type of DateType
users_cf = ColumnFamily(pool, 'users')
users_cf.column_validators['join_date'] = IntermediateDateType()
If you’re using DateType for the key_validation_class, column names, column values with a secondary index on them, or are using the DateType validated column as a non-indexed part of an index clause with get_indexed_slices() (eg. “where state = ‘TX’ and join_date > 2012”), you need to be more careful about the conversion process, and IntermediateDateType probably isn’t a good choice.
In most of cases, if you want to switch to the new date format, a manual migration script to convert all existing DateType data to the new format will be needed. In particular, if you convert keys, column names, or indexed columns on a live data set, be very careful how you go about it. If you need any assistance or suggestions at all with migrating your data, please feel free to send an email to tyler@datastax.com; I would be glad to help.
The main change to be aware of for this release is the new no-retry behavior for counter operations. If you have been maintaining a separate connection pool with retries disabled for usage with counters, you may discontinue that practice after upgrading.
This release is primarily a bugfix release with a couple of minor features and removed deprecated items.
This release adds full compatibility with Cassandra 1.0 and removes support for schema manipulation in Cassandra 0.7.
In this release, schema manipulation should work with Cassandra 0.8 and 1.0, but not 0.7. The data API should continue to work with all three versions.
This is strictly a bug-fix release addressing a few issues created in 1.2.0.
This should be a fairly smooth upgrade from pycassa 1.1. The primary changes that may introduce minor incompatibilities are the changes to ColumnFamilyMap and the automatic skipping of “ghost ranges” in ColumnFamily.get_range().
This release adds compatibility with Cassandra 0.8, including support for counters and key_validation_class. This release is backwards-compatible with Cassandra 0.7, and can support running against a mixed cluster of both Cassandra 0.7 and 0.8.
There were several related issues with overlow in ConnectionPool:
The following deprecated items have been removed:
Athough not technically deprecated, most ColumnFamily constructor arguments should instead be set by setting the corresponding attribute on the ColumnFamily after construction. However, all previous constructor arguments will continue to be supported if passed as keyword arguments.