Hello Ole, this was discussed during the security enforcement patch design
but wasn't part of the public announcement unfortunately.
The solution is to alias a KT[0] expression and then filter against it.
In you particular example that would be
from django.db.models import KT
SomeModel.objects.alias(
some_valid_alias=KT(f"data__{field_name}")
).filter(some_valid_alias__icontains="some")
Note that the above will break if `field_name` contains `__` so you might
want to consider using `KeyTextTransform`[1] directly.
Given the above works as we expected and we intended it to be the escape
hatch we should likely document it in the release notes.
Please file a ticket[2] if you believe this worthy of doing.
Cheers,
Simon
[0]
https://docs.djangoproject.com/en/5.1/topics/db/queries/#module-django.db.models.fields.json
[1]
https://github.com/django/django/blob/fd1dd767783b5a7ec1a594fcc5885e7e4178dd26/django/db/models/fields/json.py#L394C7-L416
[2] https://code.djangoproject.com/newticket
Le mercredi 28 août 2024 à 09:36:43 UTC-4, Ole Laursen a écrit :
> Hi!
>
> Regarding the .values() problem with JSON fields, has anyone as of yet
> thought about how escaping of attribute names in JSON fields is supposed to
> work?
>
> We are using a JSON field to store user-defined extension fields. So say
> the user wants a "foo" text field. Then we'd store:
>
> o.data = {}
> o.data['foo'] = "Some text"
>
> Then later, we can do
> SomeModel.objects.filter(data__foo__icontains="some") or
> SomeModel.objects.values_list('data__foo').
>
> But in reality, since this is user defined, 'foo' above comes from a
> variable so the filter() has to be done with **{'data__' + field_name +
> '__icontains': "some"}. And then what happens when the user wants a field
> called "Foo the Bar"? Or "__init__"?
>
> I haven't found a way to escape the field names in the documentation.
> Perhaps I'm not looking in the right place? It seems to me that we need
> something like JSONPath('data__', field_name) that hooks into the JSONField
> infrastructure.
>
> Just to be clear, we have this in production in a fairly large system, and
> solved the escape problem by constraining the field names from containing
> __ and some other things. But not spaces, so were bitten by the new runtime
> check on .values().
>
>
> Ole
>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/bc6e6521-c71e-45da-bff5-acff7ab65ab7n%40googlegroups.com.
