Hi Hansel,

Might be missing the point, but... If you're looking to reference the
individual fields, can you leverage the Postgres JsonField's key lookup
functionality? As per
https://docs.djangoproject.com/en/1.11/ref/contrib/postgres/fields/#key-index-and-path-lookups

A quick bit of code inspection appears to show Django's ORM assembling the
necessary SQL for you:
https://github.com/django/django/blob/b29c6c96c738bd7250a408b079dd8a4d4657849a/django/contrib/postgres/fields/jsonb.py#L90

At very least, this might give you somewhere to start from - eg: wrapping
this capability, or implementing your own get_transform for the field may
allow you to build the JSON paths manually if you're finding it's not
suitable.

Hope that helps...

James

On Fri, 27 Oct 2017 at 05:43 Hansel Dunlop <han...@interpretthis.org> wrote:

> Thank you Kuba! That's interesting. Good to know it's possible . If not,
> perhaps, advisable. I imagine my translated fields could register the
> models they're on and "as_sql" could do a quick lookup to see if we were
> referencing any of them in the particular query.
>
> I have looked at existing alternatives. In fact we're using
> django-modeltranslation currently. The API of which I think is great. But I
> don't want to continue to scale it because of the number of extra columns
> it's adding to the database and the size and ugliness of the queries it's
> generating. If we have a model with 10 translated fields and 160 translated
> languages we would have just hit postgresql's 1600 column limit and the
> queries themselves would be > 10KB. Not to mention the number of extra
> database migrations we would have generated to get there.
>
> The APIs for django-hvad and django-parler both seem to have slightly
> different goals. I want to completely avoid talking about translations in
> my general code. Set the language for a request once based on the headers
> it provides. And return an api response where any localised fields are
> provided in that language without modifying any view or serializer code.
>
> I have a custom TranslatedField that achieves these goals, quite simply.
> And it's good to know I can make further optimisations to it should I need
> to.
>
>
> On Fri, Oct 27, 2017 at 12:03 AM, Kuba <kuba.janos...@gmail.com> wrote:
>
>> Hi Hansel,
>>
>>
>> On 26 October 2017 at 18:52, Hansel Dunlop <han...@interpretthis.org>
>> wrote:
>>
>>> Hi all,
>>>
>>> So I just got a notification from Stackoverflow that this question -
>>> https://stackoverflow.com/questions/46804936/custom-django-field-type-with-modified-column-look-up-in-select-part
>>> - was just awarded the tumbleweed badge (no, votes, no answers, and no
>>> views)...
>>>
>>
>>> So throwing this open to the wider community here. I do suspect there is
>>> no way of doing this in Django. But I wish there was. Because I'm trying to
>>> create a custom translation infrastructure and it would help if I could
>>> just return the actual text in the query rather than the whole blob of json.
>>>
>>
>>
>> so just regarding this part: *Does Django have any hooks that let me
>> dynamically change the 'SELECT' part of the query?*
>>
>> Writing custom SQL backend (with only one custom part - the compiler)
>> would be one relatively "easy" way to do that. As weird as it sounds it
>> would take one method to override and mess up with.
>> django.db.models.sql.compiler.SQLCompiler.as_sql is your friend. You'd need
>> to find a clever way to figure out if given compiled sql query is the one
>> you're interested in and only then alter it, to avoid performance
>> penalties. I'm not sure it's a good idea, but it is possible. Of course
>> it's quite deep in internals so passing any custom stuff there would be
>> anyway kinda "threadlocal-magical".
>>
>> Regarding translations, just curious: have you considered django-hvad /
>> django-parler?
>>
>> Cheers,
>> Jakub
>>
>>
>>
>>>
>>> I mean maybe I could on the fly modify the db_column value. But would
>>> that be thread safe? Doubt it.
>>>
>>> --
>>>
>>>                                 Hansel
>>>
>>> _______________________________________________
>>> python-uk mailing list
>>> python-uk@python.org
>>> https://mail.python.org/mailman/listinfo/python-uk
>>>
>>>
>>
>> _______________________________________________
>> python-uk mailing list
>> python-uk@python.org
>> https://mail.python.org/mailman/listinfo/python-uk
>>
>>
>
>
> --
>
>                                 Hansel
> _______________________________________________
> python-uk mailing list
> python-uk@python.org
> https://mail.python.org/mailman/listinfo/python-uk
>
_______________________________________________
python-uk mailing list
python-uk@python.org
https://mail.python.org/mailman/listinfo/python-uk

Reply via email to