I've been looking a lot at Odata Client in the past couple of weeks, and the reason is that I'm working on a way to integrate Migrate API with Odata sources. So far, I've implemented a source plugin at my end, but I might need to add a process plugin that does a subquery on a collection related to the one selected, so it can fetch related resources as part of the migration.
The current architecture of Odata Client doesn't really allow me to do this because it exposes the query object as a service, and Drupal's service container seems to be caching it heavily. I can change the query on the fly and add methods to the OdataQuery class to clear the chain, but it still seems to be hanging onto parameters from previous requests.
To make query objects more flexible I'm considering implementing a query factory service that would generate new query objects that aren't as tightly tied to Drupal's service container, and that don't have their parameters cached. I'm not sure whether the maintainers have plans for anything similar, but I hope to avoid conflicting with existing usage patterns if possible. I'm open to suggestions and feedback; there might be something else I could try.
N/A
Create a new query factory service and possibly a new type of query class that, while it has the same API as the existing OdataQuery class, is not tied as tightly to the Drupal service container.
Implement new functionality, write tests.
None.
New factory class will contain API methods to generate query objects. I intend the query object to be at least API-compatible with existing OdataQuery objects.
None.
Active
3.1
Code
@geoffreyr is it possible to modify the current OdataQueryBase class to suit your needs and build the OdataQuery class on it?
@geoffreyr I don't know exactly what you want to achieve, but isn't InputOutputService suitable for what you want? It communicates directly with the odata client.