Added support for specifying collection name for client #66
Conversation
|
Can we reuse the existing |
|
The short answer is yes, we could reuse the options parameter if we so choose. Whether or not we should, however, is not so clear. The options object doesn't currently appear to be in use by any specific monq code, it is simply passed along to the referenced mongojs package when that gets instantiated. We could conceivable add one or more parameters to the option object and parse them out prior to passing the object along to mongojs. I chose to create a collection parameter object instead to avoid any name collision issue between potential parameters names we add and current/future mongojs option parameters name. I prefer to keep the code as it is, as we currently have a clear delineation between options bound for mongojs, and options meant for collection configuration. I am open, however, to bundling everything into the options object if that's what everyone else prefers in order to have the pull request accepted. |
|
Can the README be updated to specify the job collection name? |
This addresses issue #56 by moving where the collection name can be specified to the client/connection so that all queues and workers of that connection will use the specified collection name.
The name is not set in the options parameter, as that set of options is used by mongojs for other purposes. Instead, I've added a third parameter, 'collectionParameters'. The only valid value for that object currently is 'name'. I'm using an object here, because I'm toying with the idea of adding other collection defining variables, such as those to create a capped collection.
This is a non breaking change, and 'jobs' is still the default should you not provide a collection name to use. Below is an example using the new parameter.
var client = monq('mongodb://localhost:27017/monq_example', [], { name: '_jobqueue' });