Remove CamelCasing relationship names

[dominikb]

This is a follow-up ticket for issue #393. (and #366, #332, #307)

Although I personally use camelCased relationship names, I don't think this is a behavior we want to enforce. Especially because there have been multiple tickets regarding this feature.

The conversion happens in two places. Namely in AddsFieldsToQuery and in AllowedInclude.

I see multiple ways to handle removing the camel casing:

1. Removing the feature with a notice in the changelog.
2. Remove the feature, detect if a cast would be necessary and throw a meaningful exception.
3. Keep the camel casing and dynamically detect if a conversion is required.

What are your thoughts?

CC: @suth

[suth]

Although it's documented the behavior surprised me even the second time I ran into it. I don't think there's a problem with choosing one default over the other, but if an alias is specified I think it could be safely assumed that casting is not necessary.

Is there any impact on nested relationships as well? Haven't had to use that feature yet.

[dominikb]

Nested relationship names will be cast as well. (Can be seen in this test case)

I just found an older todo that refers to validating that included relationships do exist:

laravel-query-builder/src/Concerns/AddsIncludesToQuery.php

Line 81 in 1321c20

// TODO: Check for non-existing relationships?

Could we remove camel casing and add this check to give the user a meaningful exception?

[pionl]

Hi guys, I would recommend to be able to use a config entry to determine if CamelCase should be used?

[AlexVanderbist]

I agree that this is not the best default behaviour. Initially, I only added this because I didn't like the look of case sensitive URL parameters 🙈. Is there any reason to keep this in? I'd accept a PR that just gets rid of this on the v3 branch.

I'd accept a PR for that non-existing relationship exception as well.

[freekmurze]

We'll take a look at this in the next major version.