fixed decoding LCB value for large feilds

[fsw]

fixed decoding LCB value for fields > 250 bytes.
according to this doc:
http://dev.mysql.com/doc/internals/en/event-content-writing-conventions.html

Current implementation ignored this and was hanging waiting for more packets when VARCHAR was larger than 250 bytes.

There is also parseLCB function that is doing this exactly,
but it seems to be not used since commit 01b30f1

this probably fixes #18

[Abscissa]

Thanks for investigating and filing this pull.

The current implementation actually does attempt to handle that part of the protocol, but has a bug:

The line in question: lcb.value = packet.decode!ulong(lcb.numBytes) calls function T decode(T, ubyte N=T.sizeof)(in ubyte[] packet) which does pretty much implement what you refer to. The problem is, when the number of bytes is >1, the indicator byte of "252", "253" or "254" doesn't get skipped like it should. Your patch works because it doesn't make the same mistake.

Instead of introducing more code that does basically the same thing, I've made a commit that properly skips the indicator byte. The result is the same. I do appreciate the patch though, it did help.

I will also remove the existing parseLCB function, it's dead code like you said.

[fsw]

Thanks!

Looks much better, I will test this on my case.
Can you also take a look at this line:

https://github.com/rejectedsoftware/mysql-native/blob/1dd2996ca8331e8de735d022b99eb1955e326bdb/source/mysql/connection.d#L1322

It is in "consumeIfComplete" function:

    lcb.value = packet.consume!ulong(lcb.numBytes);

I am not sure when this is called and dont know how to test this but it seems that there is exactly the same mistake there?

cheers.

[Abscissa]

That line is fine, because just a few lines prior:

https://github.com/rejectedsoftware/mysql-native/blob/1dd2996ca8331e8de735d022b99eb1955e326bdb/source/mysql/connection.d#L1313

It already does exactly what the other function had been missing before we fixed it: If there's at least two bytes, then it skips past the initial "251/252/253/254" length byte using packet.popFront() (which pretty much the same as packet = packet[1..$]).

Admittedly, that consumeIfComplete function is nearly identical to the one we fixed (only difference is that consumeIfComplete consumes the input, whereas the other does not). So I don't know why both exist. Seems messy. I'm sure that could get cleaned up at some point, although I kinda don't wanna mess with it just yet.

[fsw]

Great, I see it now.
Thank You.