Implementing object-esque query params

[jmduke]

(I suspect this is related to https://github.com/vitalik/django-ninja/issues/86.)

I want to implement arbitrary key/value filtering. A toy example of this:

class ObjectFilter(Schema):
  metadata: dict[str, str] # `/objects?metadata[foo]=bar`

@router.get('/')
def list_objects(request, filters: ObjectFilter = Query(...))

This doesn't appear to work out of the box, and I've tried various different approaches. I suspect the issue is because the 'key' presented to django-ninja is metadata[foo], but I can't actually figure out where to plug into the framework to override the translation of the query parameters into the parsed input that's passed to the Schema. Any guidance? Thanks!

[OtherBarry]

You could write your own logic to parse data in an alternate format. a JSON string or list of JSON strings seem to be the easiest. See here for some examples.

Alternatively if there's a fixed set of possible values for filters, you could define your own schema dynamically using pydantic's create_model. I've written a filter decorator that does this here

[jmduke]

Thank you for the links @OtherBarry! It seems like the escape hatch I really want is something like fastapi's Depends — if I'm understanding it correctly, it lets me declare an arbitrary Request → obj mapping and pass it into the view function. Does Django-ninja have any such similar construct?

[OtherBarry]

The dependency injection aspect of FastAPI was intentionally excluded from Django Ninja, so there's nothing directly equivelant.

There's a few ways to do it:

• If you don't need to access the relevant data inside the view function, then you can use decorators. These are great for things like authorization, pagination, sorting, filtering, etc.
• If you do need access to the data inside the view function, then you should use a schema. With pydantic (espectially with pre=True validators) you can do all sorts of things to coax the data into the format you want. The only issue is that the auto-generated openapi schema might not line up with how the data needs to be inputted.
• Alternatively you can just write a function that takes the request or schema in as an argument and returns the data you need. This would mean you could make the openapi schema match the required inputs (or just exclude it from the schema entirely), but it would require an extra line of code in each view function. You could also turn this into a method of the relevant schema class, which might be a bit cleaner.

[jmduke]

Thank you! (I ended up going with the last option.)

[LaundroMat]

@jmduke Would you care to share your code? I'm in a similar situation and don't really know where to begin.