Is this a bug? Inconsistent use of struct/pack "q" and ">q"

[Marc Salem]

Hi All,

I'm not sure if this is a bug, but it seems a little inconsistent to me.

In pycassa-1.0.4/pycassa/types.py does not define endian-ness (so uses native):

 65 class Int64(Column):

 66     """Column for 64bit ints."""

 67     def __init__(self, *args, **kwargs):

 68         Column.__init__(self, *args, **kwargs)

 69         self.struct = struct.Struct('q')

While pycassa-1.0.4/pycassa/columnfamily.py does:

 27 if hasattr(struct, 'Struct'): # new in Python 2.5

 28    _have_struct = True

 29    _long_packer = struct.Struct('>q')

This means that if I want to use both a column family map with Int64 and autopack with cassandra type LongType for the same column family, then there are endianness issues.

This is easy to fix with a slightly tweaked copy of Int64, but wouldn't it make sense to make pycassa/types.py match the cassandra types? Also this way cassandra-cli gives sensible values.

Cheers,

-Marc

[Tyler Hobbs]

Hi Mark,

Thanks for noticing that -- you are 100% correct.

I suppose the correct way to reconcile this without breaking existing code is to create a new Column type with big-endian encoding and deprecate Int64.  I'll take care of this shortly.

Thanks again!

--
Tyler Hobbs
Software Engineer, DataStax
Maintainer of the pycassa Cassandra Python client library