[python-uk] Tumbleweed badge

[Hansel Dunlop]

Hi James, yup, that's right. And I certainly have done that automatic
transform for the WHERE part of the query. However it's the SELECT part
that doesn't have any hooks. But Kuba's suggestion of writing a custom
backend will. Though because it's just an optimisation I think I can leave
it for now. It's just nice to know that it's available.

Cheers

h

On Fri, Oct 27, 2017 at 4:18 PM, James Cheese <trust at tr00st.co.uk> wrote:

> 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/b29c6c96c738bd7250a408b079dd8a
> 4d4657849a/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 <hansel at 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.janoszek at gmail.com> wrote:
>>
>>> Hi Hansel,
>>>
>>>
>>> On 26 October 2017 at 18:52, Hansel Dunlop <hansel at 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 at python.org
>>>> https://mail.python.org/mailman/listinfo/python-uk
>>>>
>>>>
>>>
>>> _______________________________________________
>>> python-uk mailing list
>>> python-uk at python.org
>>> https://mail.python.org/mailman/listinfo/python-uk
>>>
>>>
>>
>>
>> --
>>
>>                                 Hansel
>> _______________________________________________
>> python-uk mailing list
>> python-uk at python.org
>> https://mail.python.org/mailman/listinfo/python-uk
>>
>
> _______________________________________________
> python-uk mailing list
> python-uk at python.org
> https://mail.python.org/mailman/listinfo/python-uk
>
>


-- 

                                Hansel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-uk/attachments/20171030/a18e912d/attachment.html>