Re: Should annotations allow model field constraints?

[Anssi Kääriäinen]

On Thu, 2014-12-04 at 18:04 -0800, Josh Smeaton wrote:

> 
> I've implemented https://github.com/django/django/pull/3655/ which
> effectively ignores the max_digits and decimal_places arguments in the
> base expression class. Subclasses are free to enforce validation if it
> is necessary. Further, callers using aren't required to supply bounds
> checking in this situation.

It seems wrong to throw away constraints the user has explicitly set.
So, if you say:
   
.annotate(sum_age=Sum('age', output_field=DecimalField(max_digits=3)))

then it seems that the max_digits should really be 3.

So, if the user explicitly asks for max_digits=3 in the output_field
argument, then we should enforce that. Or, alternatively we should
disallow setting max_digits for explicit output_field in expressions.
But just throwing away the value the user has explicitly set is wrong.

 - Anssi

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1417760145.22478.72.camel%40TTY32.
For more options, visit https://groups.google.com/d/optout.

Re: delegating our static file serving

[Collin Anderson]

Hi All,

I'm pretty interested in getting secure and _somewhat_ efficient static 
file serving in Django.

Quick history:
2005 - Jacob commits #428: a "static pages" view.  Note that this view 
should only be used for testing!"
2010 - Jannis adds staticfiles. Serving via django is considered "grossly 
inefficient and probably insecure".
2011 - Graham Dumpleton adds wsgi.file_wrapper to Gunicorn.
2012 - Aymeric adds StreamingHttpResponse and now files are read in chunks 
rather than reading the entire file into memory. (No longer grossly 
inefficient IMHO.)

I propose:
- Deprecate the "show_indexes" parameter of static.serve() (unless people 
actually use it).
- Have people report security issues to secur...@djangoproject.com (like 
always)
- Audit the code and possibly add more security checks and tests.
- add wsgi.file_wrapper support to responses (5-line proof of concept: 
https://github.com/django/django/pull/3650 )
- support serving static files in production, but still recommend 
nginx/apache or a cdn for performance.
- make serving static files in production an opt-in, but put the view in 
project_template/project_name/urls.py

I think it's a huge win for low-traffic sites or sites in the "just trying 
to deploy and get something live" phase. You can always optimize later by 
serving via nginx or cdn.
We already have the views, api, and logic around for finding and serving 
the correct files.
We can be just as efficient and secure as static/dj-static without needing 
to make people install and configure wsgi middleware to the application.
We could have staticfiles classes implement more complicated features like 
giving cache recommendations, and serving pre-gzipped files.

Is this a good idea? I realize it's not totally thought through. I'm fine 
with waiting until 1.9 if needed.

Collin

On Saturday, November 29, 2014 6:07:05 PM UTC-5, Collin Anderson wrote:
>
> Hi All,
>
> I think doing something here is really good idea. I'm happy with any of 
> the solutions mentioned so far.
>
> My question is: what does static/dj-static do that our built-in code 
> doesn't do? What makes it more secure? It seems to me we're only missing is 
> wsgi.file_wrapper and maybe a few more security checks. Why don't we just 
> make our own code secure and start supporting it?
> Here's basic wsgi.file_wrapper support: 
> https://github.com/django/django/pull/3650
>
> We could then, over time, start supporting more extensions ourselves: 
> ranges, pre-gziped files, urls with never-changing content, etc. That way 
> we get very, very deep django integration. It seems to me this is a piece 
> that a web framework should be able to support itself.
>
> Collin
>
>
> On Friday, November 28, 2014 9:15:03 AM UTC-5, Tim Graham wrote:
>>
>> Berker has worked on integrating gunicorn with runserver 
>>  so that we might be able to 
>> deprecate our own homegrown webserver. Windows support for gunicorn is 
>> supposedly coming soon which 
>> may actually make the idea feasible. This way we provide a more secure 
>> solution out of the box (anecdotes indicate that runserver is widely used 
>> in production despite our documentation warnings against doing so).
>>
>> On the pull request, Anssi had an idea to use dj-static 
>>  to serve static/media files. 
>> My understanding is that we would basically integrate the code for 
>> dj-static into Django and then add a dependency on static 
>> . It could be an optional 
>> dependency since you might want to serve static files differently in 
>> production, but it would likely be more or less universally used in 
>> development. We could then say that django.views.static.serve (and its 
>> counterpart in staticfiles) is okay to use in production (and I guess 
>> people are already using them in production despite our warnings that they 
>> are not hardened for production use).
>>
>> What do you think of this plan?
>>
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/bfc1eb0d-8b69-4450-bfe0-7147ef729317%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Status of #15619: logout via POST, but not GET

[Collin Anderson]

I was just thinking about this. I agree that a GET causing logout is wrong, 
and we need to not break things and I agree we need to keep the original 
view untouched so we don't break anything. _maybe_ deprecate it. The admin 
could begin using the new view right away.

On Wednesday, December 3, 2014 5:02:42 PM UTC-5, Tim Chase wrote:
>
> I've had a couple cases where browser link pre-fetching triggered 
> an unintended logout from my Django app (I haven't fully tracked down 
> the exact combination of triggering conditions, but I suspect they 
> similar to Israel Brewster's CherryPy issue mentioned on 
> comp.lang.python [1]) and was surprised that Django suffered the same 
> issue. 
>
> Researching, I found https://code.djangoproject.com/ticket/15619 
> but see that it was last modified ~10mo ago, having been opened ~4yrs 
> ago.  The current (development HEAD from git) versions of 
>
>   django/contrib/auth/views.py:logout() 
>   django/contrib/auth/__init__.py:logout() 
>
> still don't seem to contain any checks to ensure logouts can only 
> happen via POST rather than GET requests. 
>
> Is there any movement forward on resolving this so my browser 
> doesn't inconveniently boot me from the app when I don't intend to 
> log out? 
>
> -tkc 
>
> [1] 
> https://mail.python.org/pipermail/python-list/2014-December/682106.html 
>
>
>
>
>
>
> . 
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/cbd1d995-6a3b-4ce2-b31d-cf533ac65758%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Should annotations allow model field constraints?

[Josh Smeaton]

Trac user jbg has found a regression with the aggregation/annotation 
refactor #14030. The crux of the problem comes down to whether annotations 
and aggregations should respect constraints on model fields. The specific 
example raised is as follows:

Model.objects.aggregate(
sum_price=Sum('price', output_field=DecimalField(max_digits=5, 
decimal_places=2)))

Assuming the field "price" is defined as "DecimalField(max_digits=5,
 decimal_places=2)", it doesn't matter if output_field is defined or not, 
as the implicit F('price') will result in exactly the same behaviour.

Each row in the table will adhere to the max_digits and decimal_places 
restriction. It has to, it's part of the column definition. But once you 
sum those values together, they are going to overflow. The same problem 
would exist if you were to concatenate two CharFields with a max_length=10.

Ticket https://code.djangoproject.com/ticket/23941 has been opened to track 
this.

These constraints do not necessarily make sense because we're not 
persisting these values anywhere. They are read-only computations, and 
should not require bounds. If these values were to be persisted in another 
model, then the input fields on that model are required to ensure the 
values are valid.

I've implemented https://github.com/django/django/pull/3655/ which 
effectively ignores the max_digits and decimal_places arguments in the base 
expression class. Subclasses are free to enforce validation if it is 
necessary. Further, callers using aren't required to supply bounds checking 
in this situation. This is valid (with my patch):

Model.objects.aggregate(
sum_price=Sum('price', output_field=DecimalField()))

And the same goes with CharField() not requiring a max_length argument.

Can anyone see any issues with this approach?

If the above seems sensible, I'll alter the test cases to remove arguments 
like decimal_places and max_length, and update the documentation to call 
out that these kinds of arguments are not used for annotations.

Thanks,

Josh

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6190d0fd-f1b3-4982-ada5-5520a7ee0e9d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ManyToManyField with rating using 'through' on each ManyToMany relation in Django

[inoyon artlover KLANGRAUSCH]

Many thanks for the answer! Very Now I made a big step forwards:

class CustomInterestsInline(admin.TabularInline):
model = models.CustomInterests
extra = 9

class CustomSportsInlilne(admin.TabularInline):
model = models.CustomSports
extra = 9

class CustomMusicInline(admin.TabularInline):
model = models.CustomMusic
extra = 9

class CustomUserprofileAdmin(admin.ModelAdmin):
inlines = (CustomInterestsInline, CustomSportsInlilne, 
CustomMusicInline,)

The 'extra' attribute defines the amount of rows. The rating option is 
displayed also.

The nexts steps I want to accomplish:

A form for users, they can create/edit the profile. The 'interests' and 
'sports'  columns have to 
be prepopulated with all available (declared by 'active' with a Boolean) 
entries in the interests/sports table. 
If a user has an 'interest' or 'sports', he/she selects it (checkbox) and 
rates the entry.
Also the amount of entries to be selected by the user is limited to a 
defined amount (i.e. 6 or 10).
Is there any way to do it???


I started with something like this

class UserProfileForm(forms.ModelForm):

interests = forms.ModelMultipleChoiceField(
queryset=Interests.objects.all(),
widget=forms.CheckboxSelectMultiple)

sports = forms.ModelMultipleChoiceField(
queryset=Sports.objects.all(),
widget=forms.CheckboxSelectMultiple)


Best regards! :)



Am Donnerstag, 4. Dezember 2014 09:38:33 UTC+1 schrieb Yann Fouillat:
>
> Hi, 
>
> > Startet lot of investigation and the 'through' option seems to be the 
> > solution? Don't got it really because in my Admin there is NO field to 
> > choose some 'interests' and an option to rate it. 
>
> Did you try using InlineModelAdmin 
> (
> https://docs.djangoproject.com/en/1.7/ref/contrib/admin/#working-with-many-to-many-intermediary-models)?
>  
>
>
>
> -- 
> Yann FOUILLAT 
> Ingénieur Développeur 
> Makina Corpus 
> Tél : 02 51 79 80 82 
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c06c8ebc-5493-4145-9e50-8c8d119ab7f1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ManyToManyField with rating using 'through' on each ManyToMany relation in Django

[inoyon artlover KLANGRAUSCH]

Many thanks for the answer! Very Now I made a big step forwards:

class CustomInterestsInline(admin.TabularInline):
model = models.CustomInterests
extra = 9

class CustomSportsInlilne(admin.TabularInline):
model = models.CustomSports
extra = 9

class CustomMusicInline(admin.TabularInline):
model = models.CustomMusic
extra = 9

class CustomUserprofileAdmin(admin.ModelAdmin):
inlines = (CustomInterestsInline, CustomSportsInlilne, 
CustomMusicInline,)

The 'extra' attribute defines the amount of rows. The rating option is 
displayed also.

The nexts steps I want to accomplish:

A form for users, they can create/edit the profile. The 'interests' and 
'sports'  columns have to 
be prepopulated with all available (declared by 'active' with a Boolean) 
entries in the interests/sports table. 
If a user has an 'interest' or 'sports', he/she selects it (checkbox) and 
rates the entry.
Also the amount of entries to be selected by the user is limited to a 
defined amount (i.e. 6 or 10).
Is there any way to do it???


I started with something like this

class UserProfileForm(forms.ModelForm):

interests = forms.ModelMultipleChoiceField(
queryset=Interests.objects.all(),
widget=forms.CheckboxSelectMultiple)

sports = forms.ModelMultipleChoiceField(
queryset=Sports.objects.all(),
widget=forms.CheckboxSelectMultiple)


Best regards! :)







 Great, so far.
As next step, I want to 

Am Donnerstag, 4. Dezember 2014 09:38:33 UTC+1 schrieb Yann Fouillat:
>
> Hi, 
>
> > Startet lot of investigation and the 'through' option seems to be the 
> > solution? Don't got it really because in my Admin there is NO field to 
> > choose some 'interests' and an option to rate it. 
>
> Did you try using InlineModelAdmin 
> (
> https://docs.djangoproject.com/en/1.7/ref/contrib/admin/#working-with-many-to-many-intermediary-models)?
>  
>
>
>
> -- 
> Yann FOUILLAT 
> Ingénieur Développeur 
> Makina Corpus 
> Tél : 02 51 79 80 82 
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/170173fc-1736-42a5-99d2-71de6c7f9dc9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ManyToManyField with rating using 'through' on each ManyToMany relation in Django

[inoyon artlover KLANGRAUSCH]

Sorry about this... 

Am Donnerstag, 4. Dezember 2014 09:49:48 UTC+1 schrieb Florian Apolloner:
>
> Hi,
>
> this mailing list is about the development of Django itself. Usage 
> questions should go to django-users.
>
> On Thursday, December 4, 2014 1:16:13 AM UTC+1, inoyon artlover 
> KLANGRAUSCH wrote:
>>
>> I am very beginner in the programming world, so please forgive my lack of 
>> understanding...
>>
>> There is a CustomUserprofile in my models.py.. nothin very special about 
>> this
>>
>> class Interests(models.Model):
>>
>> RATING = [(y, y) for y in range(1, 7)]
>>
>> interest = models.CharField(max_length=40)
>> interest_rating = models.SmallIntegerField(choices=WEIGHT)
>>
>>
>> class CustomUserprofileInterests(models.Model):
>>
>> user = models.OneToOneField(User)
>> interests = models.ManyToManyField(
>> Interests, through='CustomInterests',
>> through_fields=('custominterest', 'interest'),
>> null=True, blank=True)
>>
>>
>> class CustomInterests(models.Model):
>>
>> WEIGHT = [(y, y) for y in range(1, 7)]
>>
>> interest = models.ForeignKey(Interests)
>> custominterest = models.ForeignKey(CustomUserprofileInterests)
>> rating = models.SmallIntegerField(choices=WEIGHT)
>>
>> I want to accomplish a rating on each relation in the 'interests = 
>> ManyToManyField' in my CustomUserprofile. The Interests-Model HAS to have 
>> an OWN, self relating rating in each 'interest' entry, NOT related to the 
>> CustomUserprofile.
>>
>> Startet lot of investigation and the 'through' option seems to be the 
>> solution? Don't got it really because in my Admin there is NO field to 
>> choose some 'interests' and an option to rate it.
>> Got absolutley NO idea how to do it... find NO way out. would 
>> appreciate any hints.
>>
>> ManyManyMany thanks in advance! cheers...
>>
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f1f87ab3-9211-4cd2-8175-eeae12620ca0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Need help about pull request #3677

[sokandpal]

Please read description of pull request 
https://github.com/django/django/pull/3677 and see changes (pull request is 
not big).

Then see 
tests.test_runner.tests.Sqlite3InMemoryTestDbs#test_transaction_support

The problem is that DiscoverRunner(verbosity=0).setup_databases() is 
broking something, so after this test my test can not pass.
The exception is like my changes about in-memory database sharing don't 
work in that moment.

When I running tests without Sqlite3InMemoryTestDbs, all works fine.

One more interesting thing - when I removed 
DiscoverRunner(verbosity=0).setup_databases(), test passes normally.
So why there are this line and what it is actually do?

Thanks!

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c8bdc37d-7781-4af6-b84f-004780f1a439%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ManyToManyField with rating using 'through' on each ManyToMany relation in Django

[Florian Apolloner]

Hi,

this mailing list is about the development of Django itself. Usage 
questions should go to django-users.

On Thursday, December 4, 2014 1:16:13 AM UTC+1, inoyon artlover KLANGRAUSCH 
wrote:
>
> I am very beginner in the programming world, so please forgive my lack of 
> understanding...
>
> There is a CustomUserprofile in my models.py.. nothin very special about 
> this
>
> class Interests(models.Model):
>
> RATING = [(y, y) for y in range(1, 7)]
>
> interest = models.CharField(max_length=40)
> interest_rating = models.SmallIntegerField(choices=WEIGHT)
>
>
> class CustomUserprofileInterests(models.Model):
>
> user = models.OneToOneField(User)
> interests = models.ManyToManyField(
> Interests, through='CustomInterests',
> through_fields=('custominterest', 'interest'),
> null=True, blank=True)
>
>
> class CustomInterests(models.Model):
>
> WEIGHT = [(y, y) for y in range(1, 7)]
>
> interest = models.ForeignKey(Interests)
> custominterest = models.ForeignKey(CustomUserprofileInterests)
> rating = models.SmallIntegerField(choices=WEIGHT)
>
> I want to accomplish a rating on each relation in the 'interests = 
> ManyToManyField' in my CustomUserprofile. The Interests-Model HAS to have 
> an OWN, self relating rating in each 'interest' entry, NOT related to the 
> CustomUserprofile.
>
> Startet lot of investigation and the 'through' option seems to be the 
> solution? Don't got it really because in my Admin there is NO field to 
> choose some 'interests' and an option to rate it.
> Got absolutley NO idea how to do it... find NO way out. would 
> appreciate any hints.
>
> ManyManyMany thanks in advance! cheers...
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/652f93dd-e34b-42ce-b675-bcb908dbfede%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ManyToManyField with rating using 'through' on each ManyToMany relation in Django

[Yann Fouillat]

Hi,

> Startet lot of investigation and the 'through' option seems to be the
> solution? Don't got it really because in my Admin there is NO field to
> choose some 'interests' and an option to rate it.

Did you try using InlineModelAdmin
(https://docs.djangoproject.com/en/1.7/ref/contrib/admin/#working-with-many-to-many-intermediary-models)?


-- 
Yann FOUILLAT
Ingénieur Développeur
Makina Corpus
Tél : 02 51 79 80 82

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/54801D6F.7090908%40makina-corpus.com.
For more options, visit https://groups.google.com/d/optout.