Add RabbitMq variables mapping

[Crell]

This will need unit tests, too. Thanks!

[maximgubar]

seems like I've messed a bit with commits, shall I create new MR ?

[Crell]

You can rebase the branch if you want to clean up the history, or I can do a squash merge when it gets merged. Either works.

However, we're trying to avoid using PHPUnit's mock library. Have a look at the other tests in the library right now; they're using testdata files to load up actual classes. That also lets us have a clearer picture of how the library behaves in "real" situations, like on someone's local laptop, where the env vars are in oddball states.

[Plopix]

What if we have more than one queue? Then we should have more than 1 DSN. So I guess the last part "messages" should be injected differently?

[Crell]

@Plopix How so? I don't think we can realistically auto-map an undefined number of relationships. The automapping here is for the common cases. If you want to do something more complex, you will almost certainly need to do your own mapping logic.

How can we ensure the defaults don't make the more complex cases harder, even if they don't help with them directly?

[Plopix]

Hey @crell,

I get your point I was just pointing out a difference with the other auto-mapped variables. If I am not mistaken the bridge overrides the variable even if it exists for all of them. And that's fine for MySQL, MongoDB, SwiftMailer.

But if we don't want to use the messages queue MESSENGER_TRANSPORT_DSN will override anyway.

And I am not sure that this is great, I don't know I wanted to share that.

I guess in this situation we could just use another relationship name and we would not be impacted by the bridge for this relationship. (which makes my comments useless)

But, as a feedback, that would be awesome if the bridge could somehow look somewhere and create all the vars needed for all the project queues.

Thanks for reading me ;)

[Crell]

I agree, it would be nifty if we could auto-map an arbitrary number of queues. I have no idea how we'd do that, though. :smile: Especially if we want to avoid a situation that breaks if you go even slightly off of the path we specify.

Perhaps providing the DSN through a formatter that users could reuse themselves if they wanted to would be better?

[Plopix]

I don't know for the DSN, not sure I got it perfectly. That would be a way to inject some code from outside when you create the ENV var?

For eZ Launchpad and to handle multi-database imports/exports we had this "kind of" issue. To know how to loop to export/import those databases we added an ENV variable that lists the information we needed.

So that could be a way. The user of the bridge could provide an ENV var, let's say. QUEUE_NAMES=something index fileprocessing and the bridge would check that var, and loops on it to create 3 transports.

That requires to create an new ENV var to create many ENV vars. It is not perfect but that would work and could be generic for other usage.