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

Scope whereTranslationLike case insensitive variant for PostgreSQL needed? #17

Closed
KMB opened this issue Jun 24, 2019 · 2 comments
Closed
Assignees
Labels

Comments

@KMB
Copy link

KMB commented Jun 24, 2019

Hello

We use PostgreSQL and would need a case insensitive variant (i.e. ILIKE) of the whereTranslationLike scope, or a similar alternative.

Basically:

public function scopeOrWhereTranslationILike(Builder $query, string $translationField, $value, ?string $locale = null)
{
    return $this->scopeWhereTranslation($query, $translationField, $value, $locale, 'orWhereHas', 'ILIKE');
}

which works great. Is there an easy way to "attach" this to the package, that would also make it update-proof? So either for everbody in the next release or somewhere in our Laravel installation outside the vendor-directory?

I tried to use the LOWER(xxx) instead, but this resulted in

product_translations.LOWER(name)

which obviously doesn't work.

Love the package, btw! Switch to Astrotomic was easy as pie.

@KMB KMB added the question label Jun 24, 2019
@Gummibeer Gummibeer self-assigned this Jun 24, 2019
@Gummibeer
Copy link
Member

Hey,
thanks for your input and your kind words. :)

Because this package is designed to work with all (laravel supported) databases I wouldn't like to add database-type specific methods like your described one.
Primary because since v11.1.0 we have the unified scopes from #2 (you already found). So it's super easy to add your own scopes.
In your case I would recommend to implement your own Translatable trait which uses the package one and there you can add your missing logic. The scopes are public and even if not listed in the interface (good question why, should we add scopes which are some kind of magic methods to the interface?) they are part of the public API and will cause a BC if changed in a not backward compatible way.
So you will be safe to add this scope by your own. I'm also pretty sure that we won't add a method with the same name in the package itself at any time.

@KMB
Copy link
Author

KMB commented Jun 25, 2019

In your case I would recommend to implement your own Translatable trait which uses the package one and there you can add your missing logic.

Thx, I will take a look at this.

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

No branches or pull requests

2 participants