Why do we use param["url"] as a unique connection pool key?

[calamont]

Hey all 🙂

I'm wondering if there was delibrate reason param["url"] was chosen as the connection pool key in the ConnectionFactory? Two cache configurations could still have the same URL. Once the first connection is created, any subsequent request will use the first parameters applied, regardless of which cache alias is requested from django.core.cache.caches.

If this is not desired behaviour I can open an PR to provide a workaround.

Thanks!

[WisdomPill]

might be a slip up, I did not create the library myself, I inherited it,
but I see your point here and I welcome any PR to solve the issue.

Just to be sure, you're referring to some options that could be used with some alias and not the others?

[calamont]

you're referring to some options that could be used with some alias and not the others?

Yeah. The use case I came up against was configuring two different timeouts. It seemed creating two aliases for these different configurations was the way forward (correct me if there is another approach I didn't see).

Because of the issue I described above, if the app used one timeout in one flow, any subsequent connection pool would use that timeout, even if the other alias was specified. The app is a monolith that uses a shared Elasticache instance, so there are a few flows were timeouts can be more generous.

I can raise a PR with the solution I ended up applying on my end, though there could be a better approach :)

[WisdomPill]

are we talking about the default timeout of an arbitrary key? or something at the connection level, like socket timeout?

[calamont]

Sorry, I meant the socket timeout and socket connect timeout.

[WisdomPill]

got it, please feel free to submit a PR and I will be happy to review it and merge it, also any feedback on the setup for the local development is welcome 😄