[python-uk] Tumbleweed badge

Hansel Dunlop hansel at interpretthis.org
Fri Oct 27 00:43:10 EDT 2017


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-uk/attachments/20171027/38f462ff/attachment-0001.html>


More information about the python-uk mailing list