vapor
Allow getting connection pools for an event loop in clients
Is your feature request related to a problem? Please describe.
It would be useful to be able to get the RedisConnectionPool for an EventLoop. For example, one may want to extend QueueContext with a Redis property, to allow using Redis from Vapor Jobs.
Describe the solution you'd like
The method pool(eventLoop:) in Application.Redis could be made public.
Describe alternatives you've considered This library could extend each type that could make use of Redis.
@wfltaylor Do you have a concrete example use case of what you’re trying to do in which the current API doesn’t allow?
Most of the API surface exposes limited access for a reason - either abstraction from a specific database engine, or to limit the chance of having bad state.
I am trying to extend QueueContext from Vapor Queues with a redis property that uses the correct event loop, similar to how Request is extended from within this library.
To do what exactly? To have access to Redis for executing commands as part of the job’s process?
This might be more of a feature request for Queues more specifically
To have access to Redis for executing commands as part of the job’s process?
Yes exactly - I need to be able to read and write to Redis during the execution of the job.
@wfltaylor you should be able to get to it from context.application.redis. Let me know if that solves it for you
@wfltaylor you should be able to get to it from
context.application.redis. Let me know if that solves it for you
Is this safe, as this instance isn't for the jobs event loop?
@wfltaylor good point, in that case I guess it depends on whether or not you are running the queue in a single event loop. If not then yeah that probably isn't safe.
@wfltaylor good point, in that case I guess it depends on whether or not you are running the queue in a single event loop. If not then yeah that probably isn't safe.
That's possible, so do you know of any way to get Redis with the correct event loop? This is done by the Redis library for requests, but I haven't been able to figure out a way to do this without using inaccessible methods.
Nope I would agree with you @wfltaylor, the pool method would need to be made public. The same would be true even if the queues library were to implement a property ourselves (although it would have to be on the queues-redis-driver package since queues itself has no knowledge of Redis)
I moved this here as it makes sense to me that a job should be given the underlying driver client for the provided event loop as part of the context