Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support namespacing #182

Open
nvie opened this issue Feb 19, 2013 · 2 comments
Open

Support namespacing #182

nvie opened this issue Feb 19, 2013 · 2 comments
Labels

Comments

@nvie
Copy link
Collaborator

nvie commented Feb 19, 2013

Currently, it's a quite dangerous to use RQ in multiple projects, while using the same Redis instance. This is because, if you pick the same queue names, workers for different projects will potentially pick up jobs intended for the other project, which leads to failed jobs.

A solution to this is to instantiate every RQ object with a name space that is reflected in the internal Redis keys that RQ uses to store its data structures.

Ideally, each RQ object grows a namespace constructor argument, that, much like the connection argument, is explicitly passed in, or provided by pushing a namespace onto a namespace stack via context locals:

with Connection(c):
    with Namespace('foo'):
        q = Queue('default')

or:

q = Queue('default', namespace='foo', connection=c)

Timeline:
This is not really a priority right now, but it would be nice to have this eventually.

@ghost ghost assigned selwin Feb 20, 2013
@luojiebin
Copy link
Contributor

@nvie Do we need this feature right now? I can work on it.

@selwin
Copy link
Collaborator

selwin commented Apr 19, 2017

This is not a priority. Instead of using the namespace argument, you could simply add your name space to the name of your queue.

Depending of how much code bloat this features will cause, I think we can scrap this idea.

@ccrvlh ccrvlh added the feature label Jan 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants