I'm adding Components to a Composite instance using the addComponent
method with the following values:
["col"
#<AsciiSerializer
me.prettyprint.cassandra.serializers.AsciiSerializer@158c4d4c>
"AsciiType"
#<ComponentEquality EQUAL>]
I insert my value into cassandra, and since this is a test I use the
same Composite instance to perform a column slice query. Upon
inspecting the results I always get a Composite whose Component values
are always instances of java.nio.HeapByteBuffer instead of the
expected String. This is true no mater what I specify for serializer
and comparator values when adding Components to my Composite instance.
Is this expected behavior?
Is there any way I can get my expected type instead of
java.nio.HeapByteBuffer?
I'm using hector "1.0-1". Any help would be greatly appreciated.
Sent from my iPhone
Sorry to crash into this discussion...
Has this perhaps to do with this post?:
http://groups.google.com/group/hector-users/browse_thread/thread/269ccdb759096384
I am having this same problem when using:
columnslice.getColumnByName(nameComposite)
columnslice has the column in question inside it, but when trying to
retreive it via getColumnByName it is not found in the hashmap because
the hashmap has stored the composite via HeapByteBuffer wich does not
matchup to nameComposite.
Any thoughts?
(Sorry again, if this is not related to the current discussion)
Regards
Hanspeter
On Dec 19, 9:52 pm, Matt Stump <mst...@sourceninja.com> wrote:
> I should mention that I'm seeing same results with row fetch as well
> as column slice.
>
>
>
>
>
>
>
> On Mon, Dec 19, 2011 at 12:45 PM, Ed Anuff <e...@anuff.com> wrote:
> > I'll take a look at it later this afternoon.
>
> > Sent from my iPhone
>
> > On Dec 19, 2011, at 12:06 PM, Nate McCall <n...@datastax.com> wrote:
>
> >> Hmm looks like from:
> >>https://github.com/rantav/hector/blob/master/core/src/main/java/me/pr...
Thanks for the update though.
Can you quickly toggle these to UTF8 in the CFDef and see if the work
as anticipated?
Initially what I loss site of is that with Composite, is that no type
info comes back from the column names, only the start and end
positions of the component. Because they are statically defined, we
assume the user knows that the component in position "2" is a "string"
because that is always the case for this column family (or else the
original write would not have validated).
You are getting the correct typing back from DC because the column
name contains a separator *and* a marker about what type the next
component is composed of (hence the dynamic nature of it).
DynamicComposite is safe to use if you adhere to the restrictions as
described out in:
https://issues.apache.org/jira/browse/CASSANDRA-3625
(Matt actually reminded me of this issue offline, ftr) the gist of
which is that you can move the types around in different rows, just
not within the same rows (or things will go horribly wrong and you
will corrupt your data if you do).
As a hack, you could still use Composite but store your own 'type
marker' component in the composite before every real component and
parse that on the way out in order to provide the functionality for
which you are looking.
Come to think, if enough people would find that useful I'll just add
it as a wrapper of some sort.
Also, dealing with caching the CfDefs is a real PITA when cluster
sizes start to grow and you have lots of endpoints talking to a
cluster.
You make a good point about exposing this functionality through the
API if we arent going to support it (admittedly, it's telling that I
needed to code dive to even remember the Composite minutia).
We are certainly open to suggestions/Patches/pull requests on API behavior.
Keep your eyes on http://wiki.apache.org/cassandra/Cassandra2474 for
the latest here.