<div dir="ltr">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. <div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>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. <br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 27, 2017 at 12:03 AM, Kuba <span dir="ltr"><<a href="mailto:kuba.janoszek@gmail.com" target="_blank">kuba.janoszek@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Hansel,<br><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On 26 October 2017 at 18:52, Hansel Dunlop <span dir="ltr"><<a href="mailto:hansel@interpretthis.org" target="_blank">hansel@interpretthis.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi all, <div><br></div><div>So I just got a notification from Stackoverflow that this question - <a href="https://stackoverflow.com/questions/46804936/custom-django-field-type-with-modified-column-look-up-in-select-part" target="_blank">https://stackoverflow.com/qu<wbr>estions/46804936/custom-django<wbr>-field-type-with-modified-<wbr>column-look-up-in-select-part</a> - was just awarded the tumbleweed badge (no, votes, no answers, and no views)... <br></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>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.</div></div></blockquote><div><br></div><div><br></div></span><div><div>so just regarding this part: <i>Does Django have any hooks that let me dynamically change the 'SELECT' part of the query?</i></div><div><br></div><div>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.<wbr>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".</div><div><br></div><div>Regarding translations, just curious: have you considered django-hvad / django-parler?</div><div><br></div><div>Cheers,</div><div>Jakub<br></div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=""><div dir="ltr"><div><br></div><div>I mean maybe I could on the fly modify the db_column value. But would that be thread safe? Doubt it. </div><span class="m_-8370318775000960780gmail-HOEnZb"><font color="#888888"><div><div><br></div>-- <br><div class="m_-8370318775000960780gmail-m_5803811239386890907gmail_signature"><div><br></div><div> Hansel</div></div>
</div></font></span></div>
<br></span>______________________________<wbr>_________________<br>
python-uk mailing list<br>
<a href="mailto:python-uk@python.org" target="_blank">python-uk@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-uk" rel="noreferrer" target="_blank">https://mail.python.org/mailma<wbr>n/listinfo/python-uk</a><br>
<br></blockquote></div><br></div></div>
<br>______________________________<wbr>_________________<br>
python-uk mailing list<br>
<a href="mailto:python-uk@python.org">python-uk@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-uk" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-uk</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div><br></div><div> Hansel</div></div>
</div></div></div>