Re: ArrayField: Bug on exact_nested_null

[Ion Alberdi]

Hello to all!
FYI a PR is available at
https://github.com/django/django/pull/16175
So far the PR unwraps ARRAY and lets psycopg2 handle these use cases.


Le mardi 11 octobre 2022 à 16:55:25 UTC+2, Ion Alberdi a écrit :

> Hi Jörg!
>
> >At this point I think ArrayField should always use ARRAY constructor to
> benefit from the additional sanity checks. But as noted earlier, ARRAY
> also exposes this weird behavior:
>
> Definitely, FYI Daniele Varrazzo from psycopg2 said 
> https://github.com/psycopg/psycopg2/issues/1507
> that
> >ARRAY[] is an always entertaining booby trap.
> and that they plan not to use any ARRAY anymore in psycopg3.
>
> Now, to fix https://code.djangoproject.com/ticket/34080
> I'll try to modify 
> https://github.com/django/django/blob/84206607d6bfd61e7f7a88b51163ffd4153e3b5a/django/contrib/postgres/fields/array.py#L238-L252
> as so that the generated template is
> > "ARRAY[%s::integer[]], "
> instead of
> >"ARRAY[%s]:integer[][]"
> when we have NULL arrays.
> Still, I'm not sure this behavior is what the django project would like to 
> follow.
> Your input on this proposal would be very welcome, whether here or in the 
> track ticket.
>
> In any case, I'll put all related info at 
> https://code.djangoproject.com/ticket/34080
>
> Thanks again!
>
>
>
> Le mar. 11 oct. 2022 à 11:33, Jörg Breitbart  a 
> écrit :
>
>> @Ion
>>
>> Well I am not deep enough into django's ArrayField for postgres to tell, 
>> which one is the desired output or right behavioral pattern. For my COPY 
>> FROM rewrite I simply tested several edge cases and tried to get as 
>> close as possible to ArrayField.
>>
>>  From postgres side of things the following is given (trying to recap my 
>> old findings):
>> - arrays only respect NOT NULL at top level (whole array)
>> - for array entries there seems to be no way to forbid NULL
>> - ARRAY constructor is not fully eqivalent to inline '{}' construction 
>> (thats not mentioned in postgres docs!)
>>
>> When playing around with inline {} construction vs. ARRAY constructor it 
>> kinda seems, that only ARRAY does certain sanity checks:
>> - multi dimension balance check
>> - empty reduction to {}
>>
>> At this point I think ArrayField should always use ARRAY constructor to 
>> benefit from the additional sanity checks. But as noted earlier, ARRAY 
>> also exposes this weird behavior:
>>
>> postgres=# select ARRAY[null,null]::int[]; --> {NULL,NULL}
>> postgres=# select ARRAY[null,ARRAY[]]::int[]; --> {}
>> postgres=# select ARRAY[ARRAY[1,2],ARRAY[3,4]]::int[]; --> {{1,2},{3,4}}
>>
>>
>> which prolly can only be circumvented by some consistency checks in 
>> python.
>>
>>
>> Now to the question, whats the right value in DB for 
>> `nested_field=[[None, None]]`:
>>
>> Imho if the None here represents a non-array type, things are clear - it 
>> should get constructed just like that:
>>
>> postgres=# select ARRAY[ARRAY[null, null]]; --> {{NULL,NULL}}
>>
>> If None represents an array-type itself (nested ArrayField), things are 
>> not so clear anymore, as we have again the issue, whether to treat 
>> things in the datatype itself (empty container) vs. sql-null:
>>
>> as empty data container:
>> select ARRAY[ARRAY[ARRAY[], ARRAY[]]]::int[];  --> {}
>>
>> as sql-null:
>> select ARRAY[ARRAY[null, null]]; --> {{NULL,NULL}}
>>
>>  From pure interface idea this could both be handled by 
>> `null=True|False` argument on the nested ArrayField. But note, that the 
>> ugly reduction on postgres side to {} for empty containers (thus 
>> null=False) creates tons of implementation edge cases during querying, 
>> as all dimension info is lost. So it might be better to always treat 
>> nested ArrayFields as sql-null to preserve some of that info.
>>
>> Not sure if any of that helps you, also changing ArrayField behavior too 
>> much might not be wanted at all.
>>
>> Overall arrays and even more nested arrays (multidimensional) in 
>> postgres feel somehow like a bad hack with their non-stable dimension, 
>> which imho results from the fact, that postgres does not store that info 
>> during column construction (int[] == int[]...[]). Bummer.
>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Django developers  (Contributions to Django itself)" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/django-developers/4OvbN0EUUsM/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to 
>> django-develop...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/a045a12e-6370-b792-9b96-35fd21566be2%40netzkolchose.de
>> .
>>
>
>
> -- 
> [image: img] 
>
>
> *Ion Alberdi*
>
>
> [image: img]  [image: img] 
>  [image: img] 
>  [image: img] 
>

Re: Permissions don't get translated in admin interface

[Thibaud Colas]

I worked on a potential fix for this yesterday at the Django London’s hack 
day with Nick (hi Nick if you’re reading this!). 

   - Here is where translation names get 
   created: 
https://github.com/django/django/blob/main/django/contrib/auth/management/__init__.py#L31
   - And where the strings are generated for 
   display: 
https://github.com/django/django/blob/main/django/contrib/auth/models.py#L78
   - As well 
   as: 
https://github.com/django/django/blob/main/django/contrib/contenttypes/models.py#L150

And here is a draft PR that makes those labels fully translate-able at 
least for the default 
permissions: https://github.com/thibaudcolas/django/pull/1

It seems to work well. As far as I could see, there’s no reason for at 
least the app name to be displayed in english (just need to switch from 
app_label to verbose_name).
On Sunday, 25 September 2022 at 14:02:33 UTC+1 Thibaud Colas wrote:

> Thank you all for your suggestions so far :) Just to give a little bit 
> more background – aside from ticket #1688 Permissions don't get 
> translated in admin interface , 
> this had also been discussed in Translation of group permissions 
>  
> on 
> the mailing list (though it’s not just for groups).
>
> To clarify what I’m after – in my opinion this needs to be treated as a 
> bug to fix in Django itself – at least for translations of built-in 
> permissions. Having a way to do this for custom ones would be nice too (see 
> for example Wagtail issue #5341 
> ). So devising how to fix 
> this would be nice, but right now this is officially a "wontfix" so this 
> would need to be addressed first.
>
> For reference, here is a screenshot of the current state, in Arabic 
> (right-to-left language so the UI is partly mirrored):
>
> [image: translations-current-state.png]
>
> Translation names aren’t translated, while their model names are 
> translated, and the app name isn’t translated ("auth" vs. app label 
> "المصادقة والتفويض" in the sidebar).
> On Sunday, 25 September 2022 at 12:12:21 UTC+1 ramez...@gmail.com wrote:
>
>> Hello 
>>
>> it's for this reason, i created this package 
>> https://github.com/RamezIssac/django-tabular-permissions
>> It displays the permissions in a table that is easily translated , and 
>> easier to work with
>>
>> Aside from a 3rd party app, a workaround (like the one suggested above) 
>> will be the way to go.
>> For Django core, it think its very hard to do it as one can also have 
>> more than one non English of languages supported .. which permission 
>> language will be recorded in the database then ?
>>
>> Screen shot for tabular permissions
>> [image: tabular_permisions.png]
>>
>> On Sunday, September 25, 2022 at 3:07:27 AM UTC+2 baido...@gmail.com 
>> wrote:
>>
>>> Thanks
>>>
>>> On Sat, Sep 24, 2022, 22:28 Danilov Maxim  wrote:
>>>
 Hi, Tribaud.

  

 In your case you can override Permission admin to show translated names 
 of permissions and for widgets you can override modelchoiceiterator

 The name of permission you can translate like model.verbose_name + 
 gettext( ‘can’) + gettext(view/change/delete) and it should be translated.

 With custom translation is a little bit  more work, but it also works. 

 I am not sure, that if override of __str__ helps, but it also possible.

  

  

 By the way - My solution DJANGO-TOF 2.version solves you ask without 
 any changes in code.

 I‘ve presented it on last Django con 2022

 We works with permissions and also custom permissions already long time 
 in Multilanguage Project and I don’t see any problem with that.

  

  

 Mit freundlichen Grüßen,

 DI Mag. Maxim Danilov

  

 +43(681)207 447 76

 ma...@wpsoft.at

  

 *From:* django-d...@googlegroups.com [mailto:
 django-d...@googlegroups.com] *On Behalf Of *Thibaud Colas
 *Sent:* Saturday, September 24, 2022 9:25 AM
 *To:* Django developers (Contributions to Django itself) <
 django-d...@googlegroups.com>
 *Subject:* Permissions don't get translated in admin interface

  

 👋 there have been a lot of discussions and tickets opened on 
 permissions translations in the past. I’m not sure what the etiquette here 
 is, hence why I’m starting a new conversation.

  

 I would like to see #1688 Permissions don't get translated in admin 
 interface  reconsidered, 
 as to me it seems like a clear bug, which affects a lot of users. Though 
 not many people might be managing permissions regularly, when you do, it’s 
 very jarring that the text is in the wrong language.

  

 I’m not sure what Django’s stance is on