Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

registerAndActivate on a different connection doesn't work with config() #559

Open
rxng opened this issue May 20, 2021 · 5 comments
Open

Comments

@rxng
Copy link

rxng commented May 20, 2021

I am creating and migrating databases on the fly, and have managed to successfully do this with seeding of data.

However, when it comes to seeding a user on this new db using Sentinel::registerAndActivate , Sentinel defaults back to the main connection and creates a user on that connection.

It doesn't respect the connection that I have specified for the new database via config('database.connection')

Is there a workaround for this?

@brunogaspar
Copy link
Member

How are you setting the active database to be used?

@rxng
Copy link
Author

rxng commented May 20, 2021

I am using config(“database.connection”)

And then php artisan migrate and seed using —database=

It all works but Sentinel doesn’t respect the database parameter

@brunogaspar
Copy link
Member

The Artisan commands like migrate and seed only set the connection for that session and after it finishes, they restore the connection to what was the default connection, you can check the Laravel source.

So you need to really change the connection at runtime, unsure if modifying the config would suffice here, as you might need to call the setDefaultConnection() method on the Database Connection instance.

@rxng
Copy link
Author

rxng commented May 24, 2021

The problem is setting default connection changes my main connection also. This interferes with creating tenant on the fly.

I solved this by creating a new model with different connection and setting Sentinel to use this model.

But Sentinel should really allow a connection parameter, that would be so much better

@brunogaspar
Copy link
Member

You're more than welcomed to submit a pull request to allow that to be changed at runtime, just keep in mind that it needs to work with both native and framework implementations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants