Thanks for the PR! As you consider this to be a bug, can you commit a unit test that shows the behaviour of this functionality on this PR, which would break on master?

@svlandeg I've updated the PR with more tests, and fixed something uncovered by those tests 👍

Looking forward to this, it fixes the issue described in this comment #12199 (comment)

Reflecting on this, I believe we could classify this as a feature rather than a bug. For the first test case, i.e. async def with_depends(model1: Model = Query(), dependency=Depends(dependency)):, this PR may constitute a bug fix (as it handled properly), but now that everything is properly flattened, this would constitute a new (and rather useful) feature.

It now properly handles multiple Pydantic models, dependencies and direct arguments. I've updated the PR title to reflect this.

Would love to see this merged, the query param models are mostly unusable for us in their current state

Also waiting for this to be merged 😺

@svlandeg Is there anything we can do to move this PR forward?

Hi! We really appreciate the time and effort spent to submit this PR. We have a high volume of PRs and we're working hard to review and classify them. We'll get back to you once we've been able to review this in detail - thanks for your patience! 🙏

Hi everyone! Any updates on this PR?

A conflict with PR #13515 has been resolved, and this PR should be able to be merged directly.

We would love to move forward with this PR, as there appears to be clear support for this feature. If there's anything we can do to help, please let us know @svlandeg

@JSCU-CNI, thank you for your work!

I haven't delved into the implementation details yet, just looked at it briefly.

As I can see, the case with BaseModel that has extra="forbid" is not handled, right?
If we have model with extra="forbid" and add more single parameters or another model, the validation of the model will fail and the error message might be not clear to understand what is happening.
I think we should handle this and show warning (or even error) on startup if such model (with extra="forbid" is combined with another model or single parameters).
What do you think?

One more thing to think about: if we have 2 models and both of them have field with the same name, will this be handled well? Intuitively, everything should be Ok, but better check it and probably add test to make it explicit.

Thank you for your comment @YuriiMotov. The implementation closely follows the original code, and only makes some necessary adjustments. It's no coincidence that PR #12944 closely resembles this code, as they probably did a similar thing.

Regarding your comment on extra=forbid, it is hard to detect whether the use-case is valid, as all models may share fully overlapping arguments. In these cases, everything will function as intended, and a warning should not be emitted. Only when models are not fully overlapping, this should trigger. I've at least added a couple of tests to cover this. I'm on the fence on whether this PR should address this more elaborately rather than leaving if unaddressed, as extra=forbid is arguably a niche edge case regardless. We could probably solve this by stating this fact in the documentation.

You're correct that everything functions properly when there are overlapping field names in different models, but I've added several test cases to verify this as well.

I've rebased and squashed all commits, and added some comments to the test cases to explain them a bit better. I've also added a test where I mix various models, just to fully cover our bases.

@JSCU-CNI, thanks for the explanation!
I think I agree about extra=forbid. Actually it's not that hard to find the cause of "Extra inputs are not permitted" error.

One more thing. There are no tests for convert_underscores. And it seems that it doesn't work correctly:

class Model3(BaseModel):
    field_1: str

class Model4(BaseModel):
    field_2: str

@app.get("/headers2")
async def get_hhh(
    h1: Annotated[Model3, Header(convert_underscores=False)],
    h2: Annotated[Model4, Header(convert_underscores=False)],
):
    return {"h1": h1, "h2": h2}

Shows parameters as param-1 and param-2 in schema.

Could this solution be extended to cover Form() parameters also? We're building an app using HTMX that is intended to degrade gracefully in situations without Javascript (so no AJAX, no JSON) and it would be extremely convenient to POST one flat form and have the backend automatically generate separate Pydantic models for us.

Looking forward to this being merged. I expected this to work as described going off of the documentation. Thanks for the work to all involved.

Looking forward as well, this will allow us to combine filters with fastapi-pagination. Cheers

Merging this PR will not alter performance

✅ 20 untouched benchmarks

_{Comparing JSCU-CNI:bug/flat-fields-for-all-models (959f944) with master (840e462)¹}

Resolved merge conflicts caused by #14371, #14564 and #14609.

This change is crucial for our team, many thanks to all those involved! 🙏

It's difficult to take full advantage of Depends with Query parameters without this feature.

It would be great if Tiangolo can have a final look at this before we merge, I've solicited his feedback 🙏