-
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
ValidatesAttributes::parseTable treats table schema prefix as connection #37580
Comments
Hi there, Thanks for reporting but it looks like this is a question which can be asked on a support channel. Please only use this issue tracker for reporting bugs with the library itself. If you have a question on how to use functionality provided by this repo you can try one of the following channels: However, this issue will not be locked and everyone is still free to discuss solutions to your problem! Thanks. |
Sorry, but I don't think you really understood what I'm reporting. This is not a question of "how it works", I'm reporting a discrepancy between how the table names works in the framework, including migrations, schema builder, and the model itself, with how it works in the validation rules. The only question I asked was if this discrepancy is intended, or if it's OK for me to submit a PR with the changes that "fixed" the ValidatesAttributes::parseTable class to work the same way it works on other areas of the framework to improve consistency. Schema::create('public.users', function (Blueprint $table) { }); // works
$table = 'public.users'; // works
DB::table('public.users')->first() //works
Rule::unique('public.users') // don't work -> Database connection [public] not configured. |
Description:
In order to be able to share some functionality between our enterprise environment we have multiple schema in our databases servers, and share some models and services via packages. Today when trying to use the Rule::unique('public.users') or even Rule::unique(User::class) the framework always throws the error "Database connection [public] not configured."
I already forked the repository and added a fix to that problem, with a unit test to validate so that if a table has a '.' and the $connection is the same as the prefix, it sets the $connection to null, but I decided to create this issue to check if the current behavior (where the $table prefix is treated like a connection) is the intended behavior before submitting a PR
The text was updated successfully, but these errors were encountered: