laravel-hashid
laravel-hashid copied to clipboard
Refactor ExistsByHash to allow chaining query builder methods
Hi,
I recently switched one of our projects to this package. For previous package I had created validation rule which I have adapted to work with yours.
This validation rule is based on Laravel Exists rule and allows chaining constraints on query builder:
validator(
['id' => User::idToHash(1)],
['id' => new ExistsByHash(User::class)->where('name', 'Admin')],
);
I also added support for custom message and attribute so you could do:
validator(
['id' => User::idToHash(1)],
['id' => new ExistsByHash(User::class)],
['id.existsByHash' => 'Incorrect :attribute'],
['id' => 'user'],
);
to get Incorrect user validation message. If no custom rule was specified there is a fallback to Exists rule message.
I added one more commit to use qualified columns in byHash scope. Current version may cause Column 'id' in where clause is ambiguous errors when used with joins.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:
Comparison is base (
8cbc50c) 100.00% compared to head (326def0) 100.00%. Report is 2 commits behind head on master.
:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@ Coverage Diff @@
## master #121 +/- ##
===========================================
Coverage 100.00% 100.00%
- Complexity 46 53 +7
===========================================
Files 5 5
Lines 106 124 +18
===========================================
+ Hits 106 124 +18
Ho @EriBloo thanks for the contributions, I noticed that if we push this, we should drop support for laravel 7-9, due to deprecation in Illuminate\Contracts\Validation\Rule
I wouldn't mind to release it under 4.x version, please also update the workflow to only include laravel 10.
Hi @veelasky. I work with Laravel 10 so I naturally pushed version compatible with it and forgot that current version is used by older Laravel as well. I don't mind refactoring it to the older Rule interface if you'd like, there is no reason to force next major version. Please tell me which approach is better for you ;)
Edit: I'm not sure how refactor would fit with custom message and attribute, would have to check it first.
Hello @EriBloo,
Given the current situation, as there hasn't been a significant feature update, I aim to continue supporting lower Laravel versions, unless the deprecated class is removed or until a major feature such as prefix/suffix support is introduced.
I understand. But I'm not sure which approach you would like to take with this PR. Would you prefere me to refactor it to support Laravel versions 7-9 or release it under 4.x as is?