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

Is there a way to prevent relationships being converted to camel case? #393

Closed
Ekion-1 opened this issue Dec 8, 2019 · 3 comments
Closed

Comments

@Ekion-1
Copy link

Ekion-1 commented Dec 8, 2019

Is there a way to prevent this package from converting relationship names to camelCase? All of the relationships in my application are snake_case.

@AlexVanderbist
Copy link
Member

Currently there isn't... I wrongly assumed camel casing relationships was required or best practice for Laravel.

I'm open for suggestions tho (maybe looking for the matching relationship regardless of case?) - feel free opening a new issue if you want to discuss implementing this :)

@pionl
Copy link

pionl commented Dec 13, 2019

Hi there, I've got the same problem. My point of view is, that it should not convert values from includes array and leave it as it is (so, if you have myRelation, you should use includes(['myRelation')).

Of course it would break current applications using the query builder - I've would suggest to use a config that would turn this behavior.

-- Edit

I've cloned the repo and noticed that maser version does not use camel case, is that correct? It appears I need to update the logic to use 2+ (I'm on 1.16.1)

@suth
Copy link

suth commented Mar 2, 2020

I've also run into this issue. Seeing as how the conversion was built around an incorrect I see no reason to leave that mistake in place. I tried extending the AllowedInclude class to omit the camel casing, but it seemed like there was somewhere else I missed that was applying it as well.

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

4 participants