ByteBuffers and StorageProxy

[Todd Burruss <bb...@expedia.com>]

My recent bug was that I was sending a zero length ByteBuffer (because I forgot to flip) for a column name.  The problem I have is that the insert was accepted by the server.  Should an exception be thrown?  The end result of allowing the insert is that the server will not restart if the data is still in the commit log (and maybe later too, not sure).

Re: ByteBuffers and StorageProxy

[Jonathan Ellis <jb...@gmail.com>]

These checks are done in ThriftValidation. If you decide to use StorageProxy
directly, the training wheels are off.
On Oct 11, 2011 11:26 AM, "Todd Burruss" <bb...@expedia.com> wrote:

> My recent bug was that I was sending a zero length ByteBuffer (because I
> forgot to flip) for a column name.  The problem I have is that the insert
> was accepted by the server.  Should an exception be thrown?  The end result
> of allowing the insert is that the server will not restart if the data is
> still in the commit log (and maybe later too, not sure).
>
>

Re: ByteBuffers and StorageProxy

[Edward Capriolo <ed...@gmail.com>]

On Tue, Oct 11, 2011 at 12:25 PM, Todd Burruss <bb...@expedia.com> wrote:

> My recent bug was that I was sending a zero length ByteBuffer (because I
> forgot to flip) for a column name.  The problem I have is that the insert
> was accepted by the server.  Should an exception be thrown?  The end result
> of allowing the insert is that the server will not restart if the data is
> still in the commit log (and maybe later too, not sure).
>
>
You may not have hit this at the thrift layer, because the AbstractTypes
have validation methods. Since StorageProxy is the "expert" interface having
redundant checks might cause code bloat. Open a jira and put in the patch.
The worse that can happen is it gets -1 ed.