any way to user QueryBuilder to insert a blob?

[Keith Freeman]

When I pass a byte[] as part of the Object[] "values" to QueryBuilder.insertInto(), it ends up as ...,'[B@6d1f7714',... in the insert statement, and the insert naturally fails.  I also tried converting it to a hex String (e.g. "0x0203"), but that turns into ...,'0x0203',...  which also doesn't work due to the quotes.

Am I missing something?

[Keith Freeman]

Sorry, I see it wants a java.nio.ByteBuffer instead of a byte[].  IMHO that's surprising, maybe it should support byte[] in addition to ByteBuffer?

[Michael Figuiere]

Indeed we rely on ByteBuffer rather than byte[]. It's always a question to choose between these two representations in Java but as it's fairly simple to convert from one to another I don't think it's a real issue.

There has been a discussion about this point here on JIRA: https://datastax-oss.atlassian.net/browse/JAVA-119

[Keith Freeman]

Ok, but then maybe the API could be more friendly?  Using '[B@6d1f7714' as a value for a byte[] in an INSERT isn't very friendly, since it definitely wouldn't be correct under any use-case.  And since I the table I was using had about 50 columns, it took me a while to spot the problem: I had to .toString() the resulting insert and scroll around in it to spot the problem.

There are probably many more-sensible behaviors, maybe throwing an exception (since obviously byte[] is not supported as a value type), or maybe just converting it to a hex String, or ??

[Alex Popescu]

Keith,

Would you venture yourself into suggesting what you'd think would be a better API? Having a practical suggestion would allow us (read force us) to think about this :-)

:- a)

[Keith Freeman]

Sure, but honestly I don't understand the "philosophy" (if that's the right word) that lead to the rejection of the JIRA issue referenced below.  IMO basic functionality (and the principle of least surprise) has been sacrificed in the name of request/result symmetry, since the current QueryBuilder API silently mishandles byte[] in every reasonable use-case.

So my suggestions would be:
1 - just convert byte[] to ByteBuffer in the current API, and let the docs inform the user that use of ByteBuffer is (slightly) more efficient and consistent;
2 - throw an exception when handed a byte[], since the API doesn't want to handle it in a useful way (so user will immediately know what he/she did wrong)
3 - same as option "1", but spit out a WARN log message (if the driver does any logging)

There may be other choices that make sense to others.

[Alex Popescu]

I'll review both the original ticket and your suggestion and try to figure out what should the driver do. Thanks a lot!

:- a)

--

:- a)

Alex Popescu

Sen. Product Manager @ DataStax

@al3xandru

[Sylvain Lebresne]

Sure, but honestly I don't understand the "philosophy" (if that's the right word) that lead to the rejection of the JIRA issue referenced below.

The goal is to have only one java type corresponding to each CQL type. And having tried otherwise initially, trying to accept as much type as possible and doing the conversion internally is messy and imo doesn't necessarily minimize the principle of least surprise in practice, I think that's a sensible choice (but I'm perfectly fine with agreeing to disagree :)).

*But*, that the QueryBuilder silently serialize a byte[] into a String is definitively an oversight and I definitely agree that it's the wrong behavior. It should throw an exception instead. I'll make sure to fix that, but feel free to open a ticket for that for tracking purposes.

--

Sylvain

[Keith Freeman]

Ok, I can understand the desire for a 1-to-1 CQL-to-Java type mapping.  I just created JAVA-160, expanding it a bit to get the API to throw an exception on any unsupported value type.

[Sylvain Lebresne]

Thanks.