Should we allow deactivating unitOfWork on create, update or delete method

[jdeniau]

Currently, we can deactivate unitOfWork for a call on the client :

sdk.getRepository('foo')
  .withUnitOfWork(false)
  .findAll()

We voluntarily throw an exception on create, update and delete call to prevent this:

sdk.getRepository('foo')
  .withUnitOfWork(false)
  .create(someEntity) // this will throw an error

We made this decision as we are not quite sure what to do in this case. Feel free to add a comment to discuss this case in this issue.

[jdeniau]

Upgrading this issue with latest thoughts:

We might want to deactivate the unitOfWork when we don't care about the result of the create, update or delete method.

Imagine a call that does fetch a item:

const item = await repository.find(1, { fields: '@id,name,type' });

later, we do have a modal that allow to change the name, but we don't care about the return

await repository.update(item.set('name', 'new name'), { fields: '@id' });

The unitOfWork will register the data with only the @id.

If later call a "type changer":

await repository.update(item.set('type', 'new type'), { fields: '@id' });

The getDirtyData will return that only the @id is known, and then send a call with:

{
  name: 'new name',
  type: 'new type',
}

We might want to disable the unit of work when "updating", as we do disable it for find method (a put is "just" a get that change some data before).