But, we could skip this initial lookup under certain (very common) conditions. For both patch and update, if the id is present but query is not present, then we can skip the originalId lookup. This covers the most basic, common use cases I believe.
// These methods could skip the `originalId` lookup
const result = await service.patch(1, data);
const result = await service.update(1, data);
// These methods must use the `originalId` lookup
const params = { query: { ... } };
const result = await service.patch(1, data, params);
const result = await service.patch(null, data, params);
const result = await service.update(1, data, params);
This would result in the most common mutation methods going from 3 DB operations to 2 DB operations! While this update would add a bit more code, I think it is worth it for the performance gain. And, it would better explain why these adapters use the originalId lookup, ultimately lowering the overall "complexity" of the code because it is more obvious why/when the originalId lookup is necessary.
For most DB adapters, we have to do an initial lookup before doing the actual patch/update database method. For more context see this issue: https://github.com/feathersjs/feathers/issues/3363.
But, we could skip this initial lookup under certain (very common) conditions. For both
patch
andupdate
, if theid
is present butquery
is not present, then we can skip theoriginalId
lookup. This covers the most basic, common use cases I believe.This would result in the most common mutation methods going from 3 DB operations to 2 DB operations! While this update would add a bit more code, I think it is worth it for the performance gain. And, it would better explain why these adapters use the
originalId
lookup, ultimately lowering the overall "complexity" of the code because it is more obvious why/when theoriginalId
lookup is necessary.