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 <tr...@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 <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 > > -- Hansel
_______________________________________________ python-uk mailing list python-uk@python.org https://mail.python.org/mailman/listinfo/python-uk
