Hi All,

When I create a node with null data, Stat.dataLength is 0.
When I create a node with byte[0] data, Stat.dataLength is 0.

I think that in the first case dataLength should return -1 instead of 0.

Which is your opinion? I will create a ticket and try to fix it if you
agree.

BR,
/César.

On Thu, May 17, 2012 at 2:21 AM, César Álvarez Núñez
<[EMAIL PROTECTED]> wrote:
> Hi All,
>
> When I create a node with null data, Stat.dataLength is 0.
> When I create a node with byte[0] data, Stat.dataLength is 0.
>
> I think that in the first case dataLength should return -1 instead of 0.
>
> Which is your opinion? I will create a ticket and try to fix it if you
> agree.

The current API is such that we treat the length of a null and an
empty string both as 0. Regardless, what you are suggesting would
change the api in a non-backward compatible way, not something we
consider outside of a major version upgrade.

Patrick

Hi Patrick,

I thoroughly agree with your opinion.

When you say "major version upgrade", you mean an increase on the 2nd digit
(for example from 3.4.X to 3.5.X) or the first digit?

Anyway, is it correct to create a Jira ticket and provide a patch although
it would not be committed until the next major version upgrade?

/César.

On Thu, May 17, 2012 at 11:41 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote:

> On Thu, May 17, 2012 at 2:21 AM, César Álvarez Núñez
> <[EMAIL PROTECTED]> wrote:
> > Hi All,
> >
> > When I create a node with null data, Stat.dataLength is 0.
> > When I create a node with byte[0] data, Stat.dataLength is 0.
> >
> > I think that in the first case dataLength should return -1 instead of 0.
> >
> > Which is your opinion? I will create a ticket and try to fix it if you
> > agree.
>
> The current API is such that we treat the length of a null and an
> empty string both as 0. Regardless, what you are suggesting would
> change the api in a non-backward compatible way, not something we
> consider outside of a major version upgrade.
>
> Patrick
>

On Fri, May 18, 2012 at 1:19 AM, César Álvarez Núñez
<[EMAIL PROTECTED]> wrote:
> Hi Patrick,
>
> I thoroughly agree with your opinion.
>
> When you say "major version upgrade", you mean an increase on the 2nd digit
> (for example from 3.4.X to 3.5.X) or the first digit?

The format is major.minor.fix (so 4.x.x would be the next major). The
last time we did a major was when we joined Apache. (2008?) Major
upgrades are very disruptive for users, so we've been reticent to do
so. Rather we favor making changes in a backward compatible way, I
don't see any way to do that here...

> Anyway, is it correct to create a Jira ticket and provide a patch although
> it would not be committed until the next major version upgrade?

That's perfectly fine, although it's likely to hang around for a while
(ie fix version 4.0.0). There are a number of API changes that we've
discussed in the past that are similarly slated. (ie changing the
version from 32bit to 64, etc...)

Patrick

> /César.
>
> On Thu, May 17, 2012 at 11:41 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>
>> On Thu, May 17, 2012 at 2:21 AM, César Álvarez Núñez
>> <[EMAIL PROTECTED]> wrote:
>> > Hi All,
>> >
>> > When I create a node with null data, Stat.dataLength is 0.
>> > When I create a node with byte[0] data, Stat.dataLength is 0.
>> >
>> > I think that in the first case dataLength should return -1 instead of 0.
>> >
>> > Which is your opinion? I will create a ticket and try to fix it if you
>> > agree.
>>
>> The current API is such that we treat the length of a null and an
>> empty string both as 0. Regardless, what you are suggesting would
>> change the api in a non-backward compatible way, not something we
>> consider outside of a major version upgrade.
>>
>> Patrick
>>