Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

'timestamp' data type is not supported #57

Open
gesterob opened this issue Jun 14, 2014 · 5 comments
Open

'timestamp' data type is not supported #57

gesterob opened this issue Jun 14, 2014 · 5 comments
Assignees
Labels
Milestone

Comments

@gesterob
Copy link

Hello,
I am using perlcassa 0.060. The cassandra DB I am interfacing with has several columns of the timestamp type: scheduled_time, generation_start_time, and generation_end_time. When I execute a select query that includes one of those columns, I get this error behavior:

EV: error in callback (ignoring): [ERROR] Attempted to unpack unimplemented data type. (timestamp) at /opt/3rdParty/lib/perl5/vendor_perl/5.16.3/perlcassa/Decoder.pm line 171.
at /opt/3rdParty/lib/perl5/vendor_perl/5.16.3/x86_64-linux-thread-multi/EV.pm line 1205.
EV::ANON/opt/3rdParty/lib/perl5/vendor_perl/5.16.3/x86_64-linux-thread-multi/EV.pm:1206 called at /opt/3rdParty/lib/perl5/vendor_perl/5.16.3/x86_64-linux-thread-multi/AnyEvent/Impl/EV.pm line 88
eval {...} called at /opt/3rdParty/lib/perl5/vendor_perl/5.16.3/x86_64-linux-thread-multi/AnyEvent/Impl/EV.pm line 88
AnyEvent::CondVar::Base::_wait('AnyEvent::CondVar=HASH(0x45d6910)') called at /opt/3rdParty/lib/perl5/vendor_perl/5.16.3/x86_64-linux-thread-multi/AnyEvent.pm line 1981
AnyEvent::CondVar::Base::recv('AnyEvent::CondVar=HASH(0x45d6910)') called at /opt/3rdParty/lib/perl5/vendor_perl/5.16.3/perlcassa/Binary/Socket.pm line 277

I would like to know if this is "on the radar" for being fixed in a future version, and if there is a workaround I can use in the meantime to access those columns of the timestamp data type.
Thank you, and best regards,
gesterob

@Lanzaa
Copy link
Collaborator

Lanzaa commented Jun 14, 2014

Timestamps should be supported, but the Cassandra devs keep changing how certain column types are reported to clients. Which version of Cassandra were you testing with?

@Lanzaa Lanzaa added the bug label Jun 14, 2014
@Lanzaa Lanzaa added this to the 0.07 milestone Jun 14, 2014
@Lanzaa Lanzaa self-assigned this Jun 14, 2014
@Lanzaa Lanzaa closed this as completed in 7d3fa56 Jun 15, 2014
@Lanzaa
Copy link
Collaborator

Lanzaa commented Jun 15, 2014

This should be fixed now. The patch is only one line. Cassandra 1.2 has DateTypes while Cassandra 2.0 has TimestampTypes. The code should now work with both versions.

@gesterob
Copy link
Author

Thank you very much for your quick attention to this! I will work with my packaging Configuration Manager to take advantage of the fix.

@gesterob
Copy link
Author

So, I still got the same error with the updated package.
(In answer to a question asked earlier, my cassandra version is 2.0.6)

I noticed in Decoder.pm that a given general data type, for example ascii, can have two lines in the %simple_packs definition:
'org.apache.cassandra.db.marshal.AsciiType' => 'A_',
and
'ascii' => 'A_',

And since my error was specifically on the datatype ’timstamp’, I added an additonal line to the %simple_packs definition:
'timestamp' => 'q>',

and with that change in place, I no longer get the error and am able to select those fields of type ‘timestamp’.
I am not expert enough to posit if your original change was insufficient for me because of some local factors with my cassandra implementation or not, and will leave for you to decide whether the 'timestamp' => 'q>' line is something you want to add.

Thank you, and best regards,
gesterob

@Lanzaa
Copy link
Collaborator

Lanzaa commented Jun 20, 2014

Thanks for letting me know. I'm glad you were able to figure out a fix that works for you. I will make sure it is incorporated into the next version.

@Lanzaa Lanzaa reopened this Jun 20, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants