[ 
https://issues.apache.org/jira/browse/CASSANDRA-2262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13003362#comment-13003362
 ] 

Sylvain Lebresne commented on CASSANDRA-2262:
---------------------------------------------

In LongType, compose() uses relative getLong(), which modifies the argument. It 
needs an absolute get instead (there is already a toInt() for that in BBUtil, 
we can add a toLong() and use it here).

Apart from that, some minor nitpicks:
  * In BytesType, we have a BBUtil.hexToBytes() instead of the FBUtil one with 
a wrap.
  * Counters could have a compose returning a Long. That would mean give a Long 
as the type parameter for AbstractCommutativeType, which breaks its supposed 
generality, but we never use this for anything else than counters anyway (I 
actually think we should get rid of AbstractCommutativeType since I'm not sure 
we have another "commutative type" very soon if ever).
  * compose() has an @Override annotations in BytesType, LexicalUUIDType and 
LocalByPartitioner (which it shouldn't as of the codeStyle)

> use o.a.c.marshal.*Type for CQL 
> --------------------------------
>
>                 Key: CASSANDRA-2262
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-2262
>             Project: Cassandra
>          Issue Type: Sub-task
>          Components: API
>    Affects Versions: 0.8
>            Reporter: Eric Evans
>            Assignee: Gary Dusbabek
>            Priority: Minor
>             Fix For: 0.8
>
>         Attachments: v2-0001-test-shows-no-roundtrip-in-BytesType.txt, 
> v2-0002-BytesType.fromString-expects-a-hex-string.txt, 
> v2-0003-compose-method-for-AbstractTypes.txt, 
> v2-0004-assume-utf8-in-CliTest-keys-dammit.txt
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> Presently, {{o.a.c.cql.Term.getByteBuffer}} manage's the conversion from a 
> parsed term to a {{ByteBuffer}} of the right contents, this should be moved 
> into the individual {{AbstractType}} subclasses (aka 
> {{AbstractType.fromString}}).
> Additionally, a method that does the inverse (returning the string 
> equivalent), needs to exists such that 
> {{AbstractType.getString(AbstractType.fromString(s)) == s}}
> Finally, for use in results decoding a method should exist that given a 
> {{ByteBuffer}} will return the appropriate object for that type.  For 
> example, {{IntegerType.compose(ByteBuffer) -> java.math.BigInteger}}, or 
> {{LexicalUUIDType.compose(ByteBuffer) -> java.util.UUID}}.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to