When starting the rqworker and rqinfo scripts with an --url parameter containing a non default database, e.g. redis://localhost:6379/2, both scripts connected db 0 instead of the desired database. Fixed this behavior by ignoring the --host, --port and --db arguments if --url is there.
Also fixed another issue with the rqinfo script, in which it defaulted to only the 'default' queue instead of finding all available queues using Queue.all().
This is mostly something you would want to test in the redis-py project,
not in RQ. The test cases make it a bit complex to read them and they
falsely suggest something interesting might be going on in them.
Otherwise find_packages() sees tests/ as something that must be installed.
Currently installing `rq` creates a `tests` directory in `site-packages`,
conflicting with projects having a local `tests` directory like rq does :)
This patches the connection object (which is either a StrictRedis
instance or a Redis instance), to have alternative class methods that
behave exactly like their StrictRedis counterparts, no matter whether
which type the object is. Only the ambiguous methods are patched. The
exhaustive list:
- _zadd (fixes argument order)
- _lrem (fixes argument order)
- _setex (fixes argument order)
- _pipeline (always returns a StrictPipeline)
- _ttl (fixes return value)
- _pttl (fixes return value)
This makes it possible to call the methods reliably without polluting
the RQ code any further.
We raise our own exception which hides the real error (often an ImportError),
making it difficult to see what happend. Instead, save the original exception
too.
This change could use far better test coverage, but I'm not sure how to
test it without refactoring more of the code than I think is reasonable
in the scope of this work.