-
Notifications
You must be signed in to change notification settings - Fork 11k
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
Queueing notifications and using multiple database connections for $notifiable #19435
Comments
Having two different users with the same id in different databases is in itself a problem. Better solution would be to use a different model for the second database where you set the connection manually class SecondUser extends User {
/**
* The connection name for the model.
*
* @var string
*/
protected $connection;
} |
Hmm... I wanted to avoid having to use different user models to be honest. They're essentially identical, just from different db's so seems most logical to have one model instead of maintaining two. But perhaps that is the only option. Why would users with the same id pose a problem? As long as you use different connections that shouldn't be an issue no? And it still doesn't explain to me why without queue'ing the notification things work perfectly fine. |
The https://laravel.com/docs/5.4/queues#creating-jobs
|
I see. That explains it. I guess I could pass along the db connection and user id to my notification class and then fetch the user from the right db in |
Hmm... So instead of relying on |
Ok, I have traced down where it goes wrong. It has to do with the notifiable, i.e. the entity you call
In I am not sure if you can classify this as a bug though. Kinda feels it is in between a conscious design decision and a limitation of the current implementation. Whatever the case may be it is rather unfortunate and unexpected behavior. Personally, I think there should at least be a warning about this in the documentation for Notifications (Sending Notifications section). |
Hello, this PR should fix your issue: #19521 But backporting it to 5.4 would be a breaking change, so I'd say that you consider your scenario as a limitation in 5.4 Sorry :) |
Ok, thanks very much. |
Description:
I am running into problems when I want to queue a notification by calling
notify()
on a user fetched through a custom database connection. This doesn't seem to be supported. If the notification is not queue'd everything works fine and the mail is send to the correct user.Steps To Reproduce:
In
routes/web.php
I have the following test route:My notification:
and my mailable:
The email doesn't get send. However, no exceptions are thrown and the notification is processed by the queue (using the
database
driver) successfully.Next, changing
routes/web.php
to the following:Now an email does get send. However, it is send to the user with id 1 in the 1st database (default connection) instead of the user I have fetched through
\App\User::on('mysql-custom')->find(1)
.Once again, when
App\Notifications\PasswordGenerated
doesn't implementShouldQueue
there is no problem confusing the different db connections and the mail is send to the right user.The text was updated successfully, but these errors were encountered: