Ticket #29048

[askpriyansh]

Hello !

I am looking to work on ticket #29048. However, it is still in the 
"Unreviewed" stage, and requires a second-opinion. The description of the 
ticket says:

Func inherits from SQLiteNumericMixin, which added an extra argument to 
as_sqlite: **extra_context. Based on feedback from other developers, it 
seems we should add this argument to each as_vendor method.

If it has already been discussed, is it alright to move the ticket to 
"Accepted" stage now ?

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/63c46562-0afd-434c-b0df-d3ac2508ef84%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Want to contribute

[askpriyansh]

Hello !

You can find some info about contributing to Django at this link 
. Look for 
tickets 
marked "easy pickings" 
 for a start. 
The details for writing your first patch can be found here 
.

Regards
Priyansh

On Tuesday, January 23, 2018 at 12:43:44 AM UTC+5:30, Anurudhbalajee 
Srikanthan wrote:
>
> Hi, I want to contribute...can someone suggest me from where to get 
> started ?
>

-- 
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/41295724-90d6-472c-847b-302ae629f6ba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Don't assume that missing fields from POST data are equal to an empty string value.

[Curtis Maloney]

On 01/22/2018 06:03 PM, Anupam Jain wrote:
Wow - I just realised that we have been losing data for sometime on our 
web platform since there were some fields in the ModelForm that were 
hidden and not being sent. They were all being overwritten as blank 
values. Thank God, we use django-reversion to track changes. Will take 
us sometime to recover the data though.


Just something vaguely related that this post prompted in me ...

My general guide is... if you're using hidden fields, then you're 
probably doing it wrong.


There are very few valid cases for passing data in hidden fields. In 
most cases you really want to exclude the fields from the model. This 
has the added benefit of protecting from a malicious user who edits the 
values of the hidden fields.


A ModelForm will _only_ update fields on the model that it has fields 
for. No matter what the user - or your code [such as clean functions] - 
manages to get into the cleaned_data dict.


--
Curtis

--
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/f06e134e-f596-3938-0bdf-daea0a56d505%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Adding a bulk_save method to models

[Tom Forbes]

Hey Neal,

Thank you very much for pointing that out, I actually found out about this
package as I was researching the ticket - I wish I had known about this a
couple of years ago as it would have saved me a fair bit of CPU and brain
time!

I think that module is a good starting point and proves that it’s possible,
however I think the implementation can be improved upon if we bring it
inside core. I worked on a small PR to add this

and the implementation was refreshingly simple. It still needs docs, a
couple more tests and to fix a strange error with sqlite on Windows, but
overall it seems like a lot of gain for a small amount of code.

Tom


On 22 January 2018 at 15:10:53, Neal Todd (n...@torchbox.com) wrote:

Hi Tom,

A built-in bulk save that's more flexible than update would certainly be
nice. Just in case you haven't come across it though, there is a package
called django-bulk-update:

https://github.com/aykut/django-bulk-update

I've found it very useful on a number of occassions where update isn't
quite enough but the loop-edit-save pattern is too slow to be convenient.

Probably some useful things in there when considering the API and approach.

Cheers, Neal

On Friday, January 19, 2018 at 5:49:48 PM UTC, Tom Forbes wrote:
>
> Hello all,
>
> I’d love for some feedback on an idea I’ve been mulling around lately,
> namely adding a bulk_save method to Dango.
>
> A somewhat common pattern for some applications is to loop over a list of
> models, set an attribute and call save on them. This unfortunately can
> issue a lot of database queries which can be a significant slowdown. You
> can work around this by using ‘.update()’ in some cases, but not all.
>
> It seems it would be possible to use a CASE statement in SQL to handle
> bulk-updating many rows with differing values. For example:
>
> SomeModel.object.filter(id__in=[1,2]).update(
> some_field=Case(
> When(id=1, then=Value('Field value for ID=1')),
> When(id=2, then=Value('Field value for ID=2'))
> )
> )
>
> I’ve made a ticket for this here: https://code.djangoproject.
> com/ticket/29037
>
> I managed to get a 70x performance increase using this technique on a
> fairly large table, and it seems it could be applicable to many projects
> just like bulk_create.
>
> The downsides to this is that it can produce very large SQL statements
> when updating many rows (I had MySQL complain about a 10MB statement once),
> but this can be overcome with batching and other optimisations (i.e the
> same values can use WHEN id IN (x, y, z) rather than 3 individual WHEN
> statements).
>
> I’m imagining an API very similar to bulk_create, but spend any time on a
> patch I thought I would ask if anyone have any feedback on this suggestion.
> Would this be a good addition to Dango?
>
>
> --
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/5988d579-7843-4c42-a6f9-1e389c58ece6%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/CAFNZOJO_yxQ-Kj4V6Ps2NtL7wfNMSkzeAu_H1c26NB8%3DgJzqug%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Want to contribute

[Anurudhbalajee Srikanthan]

Hi, I want to contribute...can someone suggest me from where to get started 
?

-- 
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/d8ca446a-b98f-4374-b120-9c1f79e5432d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: About #8500 and #27728

[Carlton Gibson]

Hi Raffaele,

I took a look at both these PRs — they both seem like good wins to me. 
I've commented briefly on the issues. 

Here I would just ask if people using the Admin have capacity to review 
that 
would be great. (If not I'm inclined to push these forwards.)

* https://github.com/django/django/pull/7765
* https://github.com/django/django/pull/7840

Kind Regards,

Carlton

-- 
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/a0dd742a-708b-46c8-a956-1d5b9824a1b7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Fellow Report - January 20, 2018

[Tim Graham]

Reviewed/committed

--

https://github.com/django/django/pull/9552 - Fixed #28857 -- Fixed invalid 
SQL when using Cast with complex expressions on PostgreSQL.

https://github.com/django/django/pull/9539 - Refs #28643 -- Added Replace 
database function.

https://github.com/django/django/pull/9605 - Fixed #29041 -- Changed 
SelectMultiple widget's multiple attribute to HTML5 boolean syntax.

https://github.com/django/django/pull/8684 - Fixed #28343 -- Add an OS 
chooser for docs command line examples.
https://github.com/django/django/pull/9602 - Fixed #29038 -- Removed 
closing slash from HTML void tags.

-- 
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/441c420c-b1b5-47cb-b1dc-6a130a4b088a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding a bulk_save method to models

[Neal Todd]

Hi Tom,

A built-in bulk save that's more flexible than update would certainly be 
nice. Just in case you haven't come across it though, there is a package 
called django-bulk-update:

https://github.com/aykut/django-bulk-update

I've found it very useful on a number of occassions where update isn't 
quite enough but the loop-edit-save pattern is too slow to be convenient.

Probably some useful things in there when considering the API and approach.

Cheers, Neal  

On Friday, January 19, 2018 at 5:49:48 PM UTC, Tom Forbes wrote:
>
> Hello all,
>
> I’d love for some feedback on an idea I’ve been mulling around lately, 
> namely adding a bulk_save method to Dango.
>
> A somewhat common pattern for some applications is to loop over a list of 
> models, set an attribute and call save on them. This unfortunately can 
> issue a lot of database queries which can be a significant slowdown. You 
> can work around this by using ‘.update()’ in some cases, but not all.
>
> It seems it would be possible to use a CASE statement in SQL to handle 
> bulk-updating many rows with differing values. For example:
>
> SomeModel.object.filter(id__in=[1,2]).update(
> some_field=Case(
> When(id=1, then=Value('Field value for ID=1')),
> When(id=2, then=Value('Field value for ID=2'))
> )
> )
>
> I’ve made a ticket for this here: 
> https://code.djangoproject.com/ticket/29037
>
> I managed to get a 70x performance increase using this technique on a 
> fairly large table, and it seems it could be applicable to many projects 
> just like bulk_create.
>
> The downsides to this is that it can produce very large SQL statements 
> when updating many rows (I had MySQL complain about a 10MB statement once), 
> but this can be overcome with batching and other optimisations (i.e the 
> same values can use WHEN id IN (x, y, z) rather than 3 individual WHEN 
> statements).
>
> I’m imagining an API very similar to bulk_create, but spend any time on a 
> patch I thought I would ask if anyone have any feedback on this suggestion. 
> Would this be a good addition to Dango?
>
>
>
>

-- 
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/5988d579-7843-4c42-a6f9-1e389c58ece6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Don't assume that missing fields from POST data are equal to an empty string value.

[Anupam Jain]

Wow - I just realised that we have been losing data for sometime on our web 
platform since there were some fields in the ModelForm that were hidden and 
not being sent. They were all being overwritten as blank values. Thank God, 
we use django-reversion to track changes. Will take us sometime to recover 
the data though.

Its been 6 years since the last post on this thread. Has anyone able to 
come up with a smart solution yet? (apart from not using Model Forms)

thanks
Anupam

On Friday, January 13, 2012 at 9:09:02 PM UTC+5:30, Mark Lavin wrote:
>
> I think Ian demonstrated exactly why this should not go in and that is not 
> all forms are ModelForms. Imagine writing a REST API which allows for an 
> optional format parameter for GET requests which is validated by a Django 
> form. With the inclusion of this proposal all clients would be forced to 
> specify the format in the GET (even if left blank) or else the form won't 
> validate. That's not much of an optional field and a large backwards 
> incompatibility.
>
> On Fri, Jan 13, 2012 at 10:20 AM, Daniel Sokolowski <
> daniel.s...@klinsight.com > wrote:
>
>> 1. How does this proposal effect default values specified on model 
>> fields? (ModelForm processing) 
>> 2. Forgive my ignorance but who has the final say if it goes in or not? 
>> And since it should be a yes what's next?
>>
>> On Thu, Jan 12, 2012 at 8:40 PM, Tai Lee > > wrote:
>>
>>> Ian,
>>>
>>> I agree that there are a lot of different ways that form data can be
>>> submitted to Django, including near endless combinations of multiple
>>> Django forms, multiple HTML forms, AJAX, etc.
>>>
>>> If we reduce the scope of our discussion and consider only a Django
>>> form (forgetting HTML forms and AJAX) and two possible scenarios:
>>>
>>> 1. Partial form data is bound to a Django form, and it is not expected
>>> to result in a call to the form's `save()` method and a change to the
>>> database. It is only intended to examine the form's validation state
>>> relating to the partial data that is bound to the form. In this case,
>>> the proposed change should have no impact.
>>>
>>> 2. Full form data is bound to a form, and it IS expected to validate
>>> and result in a call to the form's `save()` method and a change to the
>>> database. In this case, why would we ever want to assume that a
>>> character field which has no bound data, is actually bound to an empty
>>> string?
>>>
>>> This is a dangerous assumption, I think. If we intend to obtain
>>> complete data from the user, bind it to a form and save it to the
>>> database, we should be sure (as much as we can be) that the data is
>>> actually complete.
>>>
>>> Take the following pure Django example:
>>>
>>> {{{
>>> class Profile(models.Model):
>>>first_name = models.CharField(blank=True, max_length=50)
>>>last_name = models.CharField(blank=True, max_length=50)
>>>address = models.CharField(blank=True, max_length=50)
>>>
>>> class ProfileForm(ModelForm):
>>>class Meta:
>>>model = Profile
>>>
>>> profile = Profile.objects.create(first_name='Tai', last_name='Lee',
>>> address='Sydney')
>>> form = ProfileForm({}, instance=profile)
>>> if form.is_valid():
>>>form.save()
>>> }}}
>>>
>>> The profile will have no first name, last name or address. The form
>>> will produce no validation errors and will save the updated model to
>>> the database.
>>>
>>> This is very surprising and counter-intuitive to me.
>>>
>>> I think the only time we could safely make the assumption that fields
>>> with empty string values will be omitted by the UA is when we are
>>> confident that the source of the form data also makes a similar
>>> assumption that the back-end will re-normalise those missing fields
>>> back to an empty string.
>>>
>>> I'd be surprised if any UAs actually do make that assumption, because
>>> the way Django treats missing character fields does not appear to be
>>> based on any spec, and Django is not the only form processing back-end
>>> (or even the most popular one).
>>>
>>> I'm not sure I follow your simplest case example of one HTML form in a
>>> browser window and one Django Form in a view. If optional fields are
>>> left off the HTML form deliberately, without change the Form class or
>>> the view code, this is exactly when data loss will currently occur. I
>>> think you are confusing optional as in "may not be specified by the
>>> user" with optional as in "may not be processed by the form"?
>>>
>>> Cheers.
>>> Tai.
>>>
>>> --
>>> You received this message because you are subscribed to the Google 
>>> Groups "Django developers" group.
>>> To post to this group, send email to django-d...@googlegroups.com 
>>> .
>>> To unsubscribe from this group, send email to 
>>> django-develop...@googlegroups.com .
>>> For more options, visit this group at 
>>> http://groups.google.com/group/django-developers?hl=en.
>>>
>>>
>> -- 
>> You received this message because you are subscribed to the Google 

Re: Ticket #29015

[askpriyansh]

Hello !

Sorry for the trouble. I'll keep this in mind.

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/3e6c3317-e064-47eb-8ad0-b92b9a026952%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Default Authorization BackEnd Denying Permissions if Object Provided

[Carlton Gibson]

Hi Mehmet, 

Sorry for the slow reply. I didn't have capacity to return to this last 
week. 

> Hey Carlton ... What do you say?

Well, my first thought is that I don't see any great consensus for a change 
here.
I don't see it as **my** decision to make. 

This has been open a while, however, so...

I've used this API, with Django Guardian and without. It never occurred to 
me 
that there was a problem with ModelBackend's behaviour. 

For me the it (i.e. the docs) says:

> I don't do object permissions so I always return `False` if you ask. 

That seems clear, safe, and unambiguous. 

I see users read the API as hierarchical. Having thought about this issue,
ultimately, I think it's a misunderstanding (and so a docs issue).

I come back to Florian's point about what the right API should be? 

`user.has_perm("for.change_bar", obj=some_bar)`

What are we offering here? 
The ability to cycle through a number of backends checking permissions, 
**plus**
a (moderately) simple default permissions system. That's it. 
(We're not offering the most full-featured ACL-powered goodness. That's 
deliberate.)

Is this a good API for that? I think probably yes. 

Short of looking at ≈all the major frameworks out there and seeing what 
they 
offer instead, I don't see a ground for change. Not currently. 

I do see two ways forward: 

* A possible change to the docs: highlight what we're doing (again) 
  — provide the example of an alternate backend, with the other behaviour. 
  
* Possible backwards compatible refactoring of the authentication and 
authorization 
  roles of the authentication backends. Right now we have a class with two 
  responsibilities, so splitting that may make sense. (It may make future 
steps 
  clearer.) I think that would need to be done piecemeal and in PRs, with 
tests 
  and docs etc to be sensibly assessed. (It's impossible to assess code on 
the 
  mailing list, at least for me.)
  
Given the scope of the permissions system, I'm not convinced we need to 
make an 
actual code change here. (i.e. I'm not convinced about need for the second 
refactoring part.) The goal is to provide a simple but extensible system. 
We 
have that. I don't see any limitation that can't be worked around in user 
code 
if it doesn't suit. 

For me, I'd close as won't fix.
https://code.djangoproject.com/ticket/20218

Kind Regards,

Carlton




-- 
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/1fb3ac66-8d78-4393-b3ca-83cba330bccf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.