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

Eric Evans commented on CASSANDRA-2262:
---------------------------------------

I'm starting see ugly conflicts in my future; Hopefully I can piggy back on 
Gary's patches here without making a mess of things.

The attached v3* patches are:

0001-0004 Gary's patches rebased to trunk (any errors are mine).

0005 updates {{fromString}} to throw a {{o.a.c.db.marshal.MarshalException}}, 
instead of {{RuntimeException}} so that they can be caught in CQL to return 
error messages.

0006 expands {{TimeUUIDType.fromString}} to support parsing all of the CQL 
supported formats.

0007 adds exception handling to existing uses of {{AbstractType.fromString}}

0008 removes the Override annotations from BytesType, LexicalUUIDType and 
LocalByPartitioner.


bq. In BytesType, we have a BBUtil.hexToBytes() instead of the FBUtil one with 
a wrap.

What's the reasoning here?  BBUtil.hexToBytes() invokes FBUtilities.hexToBytes.

bq. 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).

I'm not up enough on the counters to judge one way or another, but it doesn't 
seem like something that would need to hold this ticket up.

> 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, 
> v3-0001-CASSANDRA-2262-test-shows-no-roundtrip-in-BytesType.txt, 
> v3-0002-BytesType.fromString-expects-a-hex-string.txt, 
> v3-0003-compose-method-for-AbstractTypes.txt, 
> v3-0004-assume-utf8-in-CliTest-keys-dammit.txt, 
> v3-0005-AbstractType.fromString-throws-MarshalException.txt, 
> v3-0006-expand-fromString-parsing-of-TimeUUIDType.txt, 
> v3-0007-catch-MarshalException-raise-RuntimeException.txt, 
> v3-0008-remove-Override-annotations.txt, 
> v4-0001-test-shows-no-roundtrip-in-BytesType.txt, 
> v4-0002-BytesType.fromString-expects-a-hex-string.txt, 
> v4-0003-compose-method-for-AbstractTypes.txt, 
> v4-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