Unexpected \u0000 in row version values

[moander]

I'm getting unexpected value on all except the latest one

Actual result:

{
 "id": "wmckinley",
 "data": {
  "fam1": {
   "tjefferson": [
    {
     "value": 3,
     "labels": [],
     "timestamp": "1523529421404000"
    },
    {
     "value": "\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0002",
     "labels": [],
     "timestamp": "1523529391871000"
    },
    {
     "value": "\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0001",
     "labels": [],
     "timestamp": "1523527967168000"
    }
   ]
  }
 }
}

Expected result:

{
 "id": "wmckinley",
 "data": {
  "fam1": {
   "tjefferson": [
    {
     "value": 3,
     "labels": [],
     "timestamp": "1523529421404000"
    },
    {
     "value": 2,
     "labels": [],
     "timestamp": "1523529391871000"
    },
    {
     "value": 1,
     "labels": [],
     "timestamp": "1523527967168000"
    }
   ]
  }
 }
}

Environment details

• OS: macos 10.13.3
• Node.js version: 8.10.0
• npm version: 5.6.0
• yarn version: 1.3.2
• @google-cloud/bigtable version: 0.13

Steps to reproduce

(async () => {

    await bt.createTable('jau1', {
        families: [
            'fam1'
        ]
    }).catch(swallowCode(6));


    let [tables] = await bt.getTables();
    tables.forEach(t => {
        delete t.instance;
        delete t.bigtable;
        console.log(t);
    })


    const table = bt.table('jau1');
    await table.createFamily('fam2').catch(swallowCode(6));

    let rows = [
        {
            key: 'wmckinley',
            data: {
                fam1: {
                    tjefferson: 3
                }
            }
        }
    ];

    await table.insert(rows);

    [rows] = await table.getRows();
    console.log(JSON.stringify(rows,null,1))

    //-
    // <h4>Retrieving Rows</h4>
    //
    // If you're anticipating a large number of rows to be returned, we suggest
    // using the {@link Table#getRows} streaming API.
    //-
    table.createReadStream()
        .on('error', console.error)
        .on('data', function (row) {
            delete row.bigtable;
            delete row.instance;
            delete row.table;
            console.log('got row', JSON.stringify(row,null,1));
            // `row` is a Row object.
        });
})().catch(err => {
    console.warn(err);
})//.then(() => process.exit());

function swallowCode(code) {
    return err => {
        if (err.code !== code) {
            throw err;
        }
    }
}

[moander]

The results I expected is also reflected in the example here:
https://cloud.google.com/nodejs/docs/reference/bigtable/0.13.x/Bigtable

// By default, when retrieving rows, each column qualifier will provide you
// with all previous versions of the data. So your `row.data` object could
// resemble the following.
//-
// {
//   follows: {
//     wmckinley: [
//       {
//         value: 1,
//         timestamp: 1466017315951
//       }, {
//         value: 2,
//         timestamp: 1458619200000
//       }
//     ]
//   }
// }

[sduskis]

This may have been fixed with #77.

[kolodny]

This should be fixed in master. @moander can you try it out with the latest master branch by running the following:

npm install googleapis/nodejs-bigtable#master

@stephenplusplus I think it may be worth pushing a release so others don't run into this behavior.

[moander]

Thank you. It works as expected using master branch.

What state would you say this library is in despite its alpha status? Is it safe to do some basic reading/writing in production?

[sduskis]

I'm the Tech Lead for Cloud Bigtable clients. Yes, it is safe to use this client in production.

We have a significant user-base for this client, and we commit to supporting our users. Towards that end, we are planning to upgrade this client to Beta in the near future. The Beta status will come with documentation and sample enhancements and some additional non-core admin features.

We did a significant amount of work on the core implementation over the last few months, and we mostly achieved the goals we set out for ourselves. We unfortunately missed this issue in our testing, but we fixed it quickly. We will be quick to respond in the future when issues like this come up.