Transactional commits prevent multiple operations on the same entity; they only execute the last operation per key. However, the way this is implemented prevents the insertion of multiple new (incomplete) keys of the same kind.
Environment details
- OS: MacOS 10.12.6
- Node.js version: 6.11.3
- npm version: 3.10.10
- google-cloud-node version: 1.1.0
Steps to reproduce
const ds = require('@google-cloud/datastore')();
function makeSomeNewEntities() {
const aNewEntity = {key: ds.key(['kind']), data: {}};
const otherNewEntityOfSameKind = {key: ds.key(['kind']), data: {}};
return [aNewEntity, otherNewEntityOfSameKind];
}
ds.insert(makeSomeNewEntities())
.then(([{mutationResults: {length}}]) => {
console.log(`Non-transactionally: ${length}`); // 2, as expected
});
ds.transaction().run()
.then(([activeTx]) => {
activeTx.insert(makeSomeNewEntities());
return activeTx.commit();
})
.then(([{mutationResults: {length}}]) => {
console.log(`Transactionally: ${length}`); // Only 1
});
But it works fine if the keys are of a different kind:
ds.transaction().run()
.then(([activeTx]) => {
activeTx.insert([
{key: ds.key(['kind']), data: {}},
{key: ds.key(['other_kind']), data: {}}
]);
return activeTx.commit();
})
.then(([{mutationResults: {length}}]) => {
console.log(`Transactionally with different kinds: ${length}`); // 2, as expected
});
A simple workaround is tricking the JSON-comparison implementation of the single-operation-per-key filter:
ds.transaction().run()
.then(([activeTx]) => {
const trickyKey = ds.key(['kind']);
trickyKey.all_up_in_your_stringify = null;
activeTx.insert([
{key: ds.key(['kind']), data: {}},
{key: trickyKey, data: {}}
]);
return activeTx.commit();
})
.then(([{mutationResults: {length}}]) => {
console.log(`Transactionally with mangled key: ${length}`); // 2, hooray
});
But it would be better to avoid this kind of tomfoolery 😉
Transactional commits prevent multiple operations on the same entity; they only execute the last operation per key. However, the way this is implemented prevents the insertion of multiple new (incomplete) keys of the same kind.
Environment details
Steps to reproduce
But it works fine if the keys are of a different kind:
A simple workaround is tricking the JSON-comparison implementation of the single-operation-per-key filter:
But it would be better to avoid this kind of tomfoolery 😉