Custom tube names in Beanstalkd for queues

[Articus]

I really miss this feature because for my application there are two environments (dev and demo) that use same Beanstalkd server. There are possible workarounds for this situation like using different queues or additional fields for job payload but I believe that separating queue name from tube name is a better solution.

[juriansluiman]

Nice addition to have the flexibility to provide a custom tube name independent of the queue name :+1:

Now, you're supplying a queue/tube map in the beanstalk options. We have rather a separated key for specific queue options. Could you rewrite the config so it uses the queue key instead of a sub-key of the general beanstalkd configuration?

I'd imagine you can set the tube like this:

'queues' => [
    'my-queue-name' => [
        'tube' => 'my-tube-name',
    ],
]

[Articus]

Thanks :) Sure, will do something similar to DoctrineOptions then. I just thought that tube name is more like database name for Doctrine ORM than table name for specific database and that it is an attribute of the connection to Beanstalkd server.

[juriansluiman]

@Articus re the tube name vs the table name. Perhaps I am misunderstanding something, so please elaborate on your use case.

This module connects with a single beanstalkd instance, on a server with a given port. In comparison with SlmQueueDoctrine this is the (My)SQL server with given host, port (and db table, if you want). SlmQueue supports different queues, for example for distinct task or to supply jobs to different workers. So one beanstalkd instance can handle multiple queues. Because beanstalkd supports tubes, a queue in SlmQueue is similar to a tube in beanstalkd.

Now if I understand correctly, you have a single beanstalkd instance (= server) where you want to push jobs to from production and a staging environment. Hence, your app uses the same queue name internally but wants to use a different tube name in its connection to beanstalkd. In my opinion this is a specific queue config option which can be tuned per installation, therefore the queues key is the right place to provide per-queue config. Although, if above scenario isn't the one you are experiencing, the solution might not be the proper one.

[juriansluiman]

PS. For now I would be fine if you just inject the tube name. You do not need the options. Even further, afaik you can just swap $name with the tube name instead of the queue name. The queue itself keeps the same, the factory only injects the tube name (when specified) instead of the queue name. The factory uses the queue name as fallback when no tube name is specified.

[Articus]

Your description of my current scenario is correct. By making analogy with SlmQueueDoctrine I just tried to show what led me to misunderstanding of configuration layers.

For SlmQueueDoctrine they are just better separated because it is possible to store queues in different databases and some other components can use these databases as well.

For SlmQueueBeanstalkd there is only one Beanstalkd server that is used only by queue component. So it was a bit unclear for me if separate configuration is needed (as you suggested) or it is valid to continue using dedicated Bealstalkd configuration.

Anyway I already made and tested changes you asked for, just need few minutes to find out the right way to update initial pull request :) It should also fix Travis CI "grumbling"

[juriansluiman]

Might be a good idea to have multiple Pheanstalk services for different connections :) I'd prefer to keep the features separated: this single one will be a really good addition, and a PR for the ability to split queues among multiple connections will likely be merged too ;)

[Articus]

Yep, it might be helpful, but I would rather wait to see someone who needs it for active project first ;) Do you want anything else to be adjusted before accepting this pull request?

[Articus]

Is there anything else to be adjusted? I fixed that Code Sniffer warning so now the only thing that randomly fails Travis CI build is Composer taking too long to download dependencies.

[juriansluiman]

@Articus sorry, didn't got the updates you made. All good, thanks for the help!

[juriansluiman]

Now v0.4.2 is released

[Articus]

Thanks to you for nice library :)