cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Evans (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CASSANDRA-2262) use o.a.c.marshal.*Type for CQL
Date Tue, 08 Mar 2011 16:50:59 GMT

    [ 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

Mime
View raw message