Add connection config option

[rizqidjamaluddin]

Can we add a config option to set which DB connection to use? The only real change is to line 149 of the service provider to use $config['doctrine::doctrine.connection'] ?: $config['database.default'] and, of course, the line in the config file.

Rationale: I'm using the database for things other than doctrine's entities, so I'd like doctrine to use its own database connection. Also just generally a good config option to have.

I can submit a PR for this if approved.

[kirkbushell]

I'd like to ask why or what you'er doing that is resulting in numerous database connections between platforms/libraries. We tried doing this in one of our applications - was very much an antipattern.

That said, I believe this PR addresses that concern: #55

[rizqidjamaluddin]

The direct case here is that laravel wants to put its own migrations table in the default connection. I want doctrine to keep itself clean (remove tables as entities are deleted), and having doctrine work upon the same database connection as the migration table causes the schema tool to keep suggesting to remove it.

The simplest solution for that is just to have doctrine use its own connection, and everything auxiliary elsewhere. Or try to maintain entity removal manually, which wouldn't be the end of the world, but is still there; I would prefer to let doctrine take care of itself.

There are other cases where this happens as well. We connect to a separate database for logging, for instance. Having this as an option is just generally good practice, rather than assuming everyone's going to be using their default connection all the time.

[kirkbushell]

@rizqidjamaluddin that shouldn't be happening when you run doctrine migrations via the appropriate command. You shouldn't be using both - it's one or the other. The pull request I linked above should support multiple connections in future.

I repeat - you really don't want to be using laravel AND doctrine for managing your shema. Migrations would be the least of your worries.

[rizqidjamaluddin]

Is there a particular reason why? To be clear - I'm not using doctrine migrations. I'm having a mechanism that takes the output from schema:update, throwing it to a laravel migration file, and having laravel manage those, because I'm also having other tables/data not being managed by doctrine - so it felt logical to maintain everything through one migration schema, as you said. It seems to be working well, except for the problem I described. I can also turn on saveMode in getUpdateSchemaSql and it works fine, aside from it not removing unused data, obviously.

(Yes, the mechanism I use sounds weird, but unifying the migration management makes a lot of sense to me. I was pretty hesitant about it too, so I just tried it out and it seems to work fine.)

I'll wait for official support regarding multiple connections, then, thank you. I'll monkey patch it for now till it gets merged in.

[kirkbushell]

Very interesting approach, that's for sure. Um - you can try working with the branch/revision that is in the PR. It hasn't been merged in yet simply because it needs more testing.

I'll close this for now either way - as it is resolved/managed in PR #55 .

[rizqidjamaluddin]

Thanks for the feedback. Yeah, that PR should do, it wasn't high up in the PR list so I didn't see it. If you've got a better approach for managing the migrations, I'd love to talk about it - I'm looking for a better solution if there is one. IRC may be a better bet so as not to clutter github.

[kirkbushell]

Yeah sure - hit up Oddman :)

[rizqidjamaluddin]

I'll see you on dev-discussions or offtopic. :)