Update specific keys within nested Django JSONField data

[askpriyansh]

Hello !

I have come up with a solution to #29112 
, using jsonb_set function. 
However, this function is only available from PostgreSQL 9.5, and we need 
to give support for PostgreSQL 9.4 as well.

We can use PL/Python extension to write a custom function. I am planning to 
add the function definition in a class that extends Func, and use it with 
this extension. Is this the correct way of approaching the problem ? Any 
ideas will be welcome. 


Regards
Priyansh


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/07f23d29-a3fa-4ac8-89df-b7d7a3a66ebf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Google Summer of Code 2018

[askpriyansh]

Hello !

I am still looking for Track tickets and other references (including 
third-party solutions) to formalise the idea. The work I propose should ideally 
make the process of using any arbitrary backend (like Google App Engine) much 
easier and uniform for every datastore.

The exams will take up no more than ten days (should have clarified this, 
apologies), it's just that they will take place at the start of the period I 
mentioned them in.

I'll do more research and get back to you in this. Meanwhile, ideas from the 
community will be of great help.

Thanks !
Priyansh

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/475b6c86-d5c8-4bb3-b994-4faae686edbf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Support for `Q` objects in `get_or_create` and `update_or_create`

['Mike Lissner' via Django developers (Contributions to Django itself)]

OK, I created a ticket, but I fear I'm not the best person to get the docs
ironed out. I took a stab at it, but it was terrible and I got the sense
it'd get rejected for not explaining things properly/well. Perhaps somebody
else can pick this up:

https://code.djangoproject.com/ticket/29148

Mike

On Tue, Feb 20, 2018 at 6:39 PM Adam Johnson  wrote:

> I think it's perfectly sane to document the filter + get_or_create combo,
> feel free to open a ticket and pull request
>
> On 20 February 2018 at 20:26, 'Mike Lissner' via Django developers
> (Contributions to Django itself) 
> wrote:
>
>> This is my first message here, and sure enough I'm necromancing this
>> thread from 2016!
>>
>> Below there's a message about how to use Q objects with get_or_create by
>> chaining them. This works! But it's not documented. Is it crazy to document
>> this?
>>
>> I think I used the advice in this thread a while back to write some code,
>> but when I came upon the code today, it baffled me. I went to the docs, but
>> there was no mention of this technique there, and so, here I am again at
>> this thread.
>>
>> Thanks,
>>
>> Mike
>>
>> On Tuesday, August 16, 2016 at 12:27:30 PM UTC-7, Flavio Curella wrote:
>>>
>>> It didn't occur to me that it could be done that way. Thanks!
>>>
>>> I'm closing the ticket as 'invalid'
>>>
>>>
>>> On Tuesday, August 16, 2016 at 2:03:02 PM UTC-5, charettes wrote:

 Hi Flavio,

 Is there a reason we can't document chaining filter() with these
 methods when
 querying with Q() objects?

 Person.objects.filter(
 Q(first_name='George') | Q(first_name='Bruce')
 ).get_or_create(defaults={'last_name': 'Harrison'})

 If `defaults` was stil only passable as a kwarg this could have worked
 but at
 this point I don't think it's worth the additionnal complexity as
 there's no way
 to introduce a fully backward compatible API without deprecating passing
 `defaults` as the first arg.

 Even if we were to agree on a new unlikely used kwarg name to specify
 the query
 object the `(get|update)_or_create` APIs would end up disgressing from
 the `filter()`
 and `get()` ones which is the main objective of this proposed change I
 beleive.

 Simon

 Le mardi 16 août 2016 13:57:25 UTC-4, Flavio Curella a écrit :
>
> I'm thinking about adding support for `Q` to `get_or_create` and
> `update_or_create`. I've summarized my thoughts at
> https://code.djangoproject.com/ticket/27070.
>
>
> I have a couple of unsolved question; the most critical is the one Tim
> raises: if we were to add another keyword argument to those methods, how
> much of an impact will it have? Can we find a name that we can be
> reasonably confident is not used as a model field by anybody (or a _very_
> small number of users)?
>
>
> Thanks,
> –Flavio.
>
 --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>
>
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/6c1285c8-94da-49bc-bbbf-c76b8e6cfb3e%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Adam
>
> --
> 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/e3sJ6OiHEd0/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMyDDM2SjuQX3E828znmVaBMFjjP7whBk24qtwpAD29scsuDcA%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Mike Lissner
Executive Director
Free Law Project
@freelawproject
https://free.law/donate/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emai

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

[Josh Smeaton]

I agree that the names are misleading and we should probably provide better 
names. I'm wary of deprecating the old names because it'll create a lot of 
churn (some of which would be the right thing to do). Maybe we could just 
alias and warn when using the old name, leaving a decision on deprecation 
until some time in the future.

On Monday, 29 January 2018 03:14:27 UTC+11, Stuart Cox wrote:
>
> In my experience, misuse of mark_safe() — i.e. marking stuff safe which 
> *isn’t* actually safe (e.g. HTML from a rich text input) — is one of the 
> biggest causes of XSS vulnerabilities in Django projects.
>
> The docs warn to be careful, but unfortunately I think Django devs have 
> just got too used to mark_safe() being *the way* to insert HTML in a 
> template. And it’s easy for something that was safe when it was authored 
> (e.g. calling mark_safe() on a hard-coded string) to be copied / 
> repurposed / adapted into a case which is no longer be safe (e.g. that 
> string replaced with a user-provided value).
>
> Some other frameworks use scary sounding names to help reinforce that 
> there are dangers around similar features, and that this isn’t something 
> you should use in everyday work — e.g. React’s dangerouslySetInnerHTML.
>
> Relatedly, this topic 
>  
> suggested 
> making it more explicit that mark_safe() refers to being safe for use in 
> *HTML* contexts (rather than JS, CSS, SQL, etc).
>
> Combining the two, it would be great if Django could rename mark_safe() to 
> dangerously_trust_html(), |safe to |dangerously_trust_html, @csrf_exempt to 
> @dangerously_csrf_exempt, etc.
>
> Developers who know what they’re doing with these could then be encouraged 
> to create suitable wrappers which handle their use case safely internally — 
> e.g.:
>
> @register.filter
> def sanitize_and_trust_html(value):
> # Safe because we sanitize before trusting
> return dangerously_trust_html(bleach.clean(value))
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/05de4602-5c44-41bf-b675-ab15d69fb46d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

[Collin Anderson]

> Maybe we could just alias and warn when using the old name, leaving a
decision on deprecation until some time in the future.

I'm a fan of delaying deprecation/removal if we do change it. :)

On Wed, Feb 21, 2018 at 4:41 PM, Josh Smeaton 
wrote:

> I agree that the names are misleading and we should probably provide
> better names. I'm wary of deprecating the old names because it'll create a
> lot of churn (some of which would be the right thing to do). Maybe we could
> just alias and warn when using the old name, leaving a decision on
> deprecation until some time in the future.
>
> On Monday, 29 January 2018 03:14:27 UTC+11, Stuart Cox wrote:
>>
>> In my experience, misuse of mark_safe() — i.e. marking stuff safe which
>> *isn’t* actually safe (e.g. HTML from a rich text input) — is one of the
>> biggest causes of XSS vulnerabilities in Django projects.
>>
>> The docs warn to be careful, but unfortunately I think Django devs have
>> just got too used to mark_safe() being *the way* to insert HTML in a
>> template. And it’s easy for something that was safe when it was authored
>> (e.g. calling mark_safe() on a hard-coded string) to be copied /
>> repurposed / adapted into a case which is no longer be safe (e.g. that
>> string replaced with a user-provided value).
>>
>> Some other frameworks use scary sounding names to help reinforce that
>> there are dangers around similar features, and that this isn’t something
>> you should use in everyday work — e.g. React’s dangerouslySetInnerHTML.
>>
>> Relatedly, this topic
>>  
>> suggested
>> making it more explicit that mark_safe() refers to being safe for use in
>> *HTML* contexts (rather than JS, CSS, SQL, etc).
>>
>> Combining the two, it would be great if Django could rename mark_safe() to
>> dangerously_trust_html(), |safe to |dangerously_trust_html, @csrf_exempt to
>> @dangerously_csrf_exempt, etc.
>>
>> Developers who know what they’re doing with these could then be
>> encouraged to create suitable wrappers which handle their use case safely
>> internally — e.g.:
>>
>> @register.filter
>> def sanitize_and_trust_html(value):
>> # Safe because we sanitize before trusting
>> return dangerously_trust_html(bleach.clean(value))
>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/05de4602-5c44-41bf-b675-
> ab15d69fb46d%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFO84S7x0y07eY4uYO2cKCe4%2B8jo9x%3DrO0QA3EAbJvU1pmbJ5Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.