Refactor batch request mechanism

[ssssarah]

Motivated by:
Future batch retrieval feature, that could benefit from the existing mechanism, under some changes. + Aligning batch/single request logics (remove duplicate logic)

For the methods: Deprecate, Tag, Update, Update Schema, Register:

• The logic of knowing which http method to use, which url to target, what query params to use, what headers to use, what payload to give and what exception to throw on error is prepared in prepared_methods.py. This information will either be used by the requests.request method (for synchronous calls, when performing these operations for one resource) or aiohttp.ClientSession.request (for asynchronous calls, when performing these operations for multiple resources)

• When using BatchRequestHandler.batch_request_for_resources, the appropriate prepare_x should be provided. Everything else can either be found in the service instance or the kwargs.

• BatchRequestHandler.batch_request provides a way to run a list of tasks. These tasks will be initialised using the task_creator parameter this method requires.

• In the case of the methods cited above (deprecate, tag, update…), they all have the same task_creator method, which is defined by BatchRequestHandler.create_tasks_for_resources

In the effort to remove duplication of logic, some differences were spotted:

• Batch registration only targeted POST regardless of the presence of an id specified in the payload (https://bluebrainnexus.io//docs/delta/api/resources-api.html#create-using-post). This has been fixed, and now batch registration targets either POST or PUT, like single-resource registration did before (and still does).
• The setting of the context after registration of a resource is done differently between single resource registration and multiple resource registration.

  nexus-forge/kgforge/specializations/stores/bluebrain_nexus.py

  Line 119 in 02da102

  if not hasattr(result.resource, "context"):

  vs
  

  nexus-forge/kgforge/specializations/stores/bluebrain_nexus.py

  Line 190 in 02da102

  if not hasattr(resource, "context"):

  
  This has not been addressed in this MR but should be in the future.

[crisely09]

about this id/context addition to the resource when registering... it doesn't seem like a extreme change to make one general callback, I would say ... go for it if you already thought of a way

[ssssarah]

What do you mean by a general callback?

[crisely09]

there is a default callback method, that is shared within all the possible resource tasks, that is what I meant, why not to move the option of adding id/context there, to have one single method?

[ssssarah]

The setting of the resource.id and context look harmless at first glance so I could see them happening for any resource operation. But are they really harmless?

First there's the question of harmonising the register_one and register_many callbacks before even thinking of making them the same as the other operations'

[crisely09]

@MFSY any thoughts?