Enabled NULL values in prepared statements.

[omikro2n]

So far, users cannot send a NULL value among the parameters of prepared statement. This update should enable sending NULL values by push-backing them to the binary stream of parameters. However, to carry the NULL value, the parameter container has to store pointers instead of the actual values. User will now be able to push_back_null(), the NULL pointer will be carried in the container and checked when encoding to be sent as the appropriate binary representation of NULL (inspired here by the corresponding part of code in the Java driver).

[benelgiac]

Hi!

I have been trying to accomplish the exact same thing ( see my pull request #30 ) but I was not sure that "null" byte in binary cql protocol could be used for fields of any value (see also my question on stack overflow )

Just for confirmation, when you perform a prepared INSERT and use the "push_back_null" for a given column, what is the representation you get from cqlsh SELECTing the record inserted?

Thanks, will test this as soon as I can

[omikro2n]

Hi, thanks for the quick feedback!
I've just re-tested it (and added a minor bugfix) and the cqlsh seems to confirm the insertion of a NULL value after using the push_back_null().
I think the issue with your approach was that the null value was in fact treated as an -1 int and as such gets "wrapped" later in the process... To correctly send the binary null interpretation, you have to keep the null information one level deeper, roughly saying - therefore the added pointer level in my solution.

[jstasiewicz]

Good to see that you guys are taking care of this! However, I'll be much happier about merging this PR if you get rid of raw pointers. Perhaps smart ptrs of some kind would do the job? Or boost::optional? Or one of the pointer containers from boost?

Thanks,
JS

[omikro2n]

Right, I see your point - switched to boost::shared_ptrs, if it's okay like this... The only small hesitation I had was whether to check then explicitly for "!= NULL" or exploit the boolean context conversion in the similar sense. I've decided for the first option, it seems to me that it's a bit more understandable like that...

[jstasiewicz]

Good job, thanks!