Re: future of QuerySet.extra()?

[Anssi Kääriäinen]

On Tue, Aug 4, 2015 at 8:06 AM, Tai Lee  wrote:
> I think that while `extra()` gets a bad rap, it is extremely useful when
> creating generic pluggable apps, and I for one would miss it if it were to
> be removed.

The idea is that expressions should do everything that extra() can do.
There might be cases where this is not yet true, but I hope we will
get there in a couple of releases.

The extra() method should not  be better than expressions for reusable
apps. Actually the contrary, with expressions you can generate
different SQL for different databases.

> In a comment on #7231 a few years ago I wrote:
>
>> I can't reply to the discussion linked on Google Groups anymore, but
>> wanted to add my comment that I have found many uses for .extra() and also
>> hit the limitation of being unable to add left outer joins to a query
>> generated by the ORM. I would not like to see it disappear in favour of raw
>> SQL.
>>
>>
>> My current use case is for joining reverse generic relations on queries
>> against a model that does not have a GenericRelation field back to the
>> generic model (because I don't know which models it will be used with -- I
>> can't add models to 3rd party code).
>>
>>
>> To require the whole query in raw SQL in order to join generic relations
>> would mitigate the pluggability of the generic model in question.
>
>
> While `raw()` may be allow you to get model instances from any custom SQL,
> it will often be prohibitively complicated or impossible to provide generic
> queryset methods that extend 3rd party apps. The RawSQL expression example
> given would appear to execute a subquery for each row of the result set. It
> wouldn't seem to help with the example above, unless I'm missing something?

What we want is something like
qs.add_relation(new_rel=Relation(SomeModel, on_clause=some_expression,
allow_nulls=True))

The some_expression variable generates sql for the ON clause, and
allow_nulls=True means the join will be LEFT join. Typically
some_expression could be something like Q(id=F('new_rel__other_id')) &
Q(new_rel__lang='fi').

The effect of this would be that the qs has a new relation called
new_rel to SomeModel, and that relation could be used in other query
constructs (for example .filter(new_rel__somef__lte=10)).

Making this work is high priority to me.

 - 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/CALMtK1GQ1oAgeSCgNvNu%3D1ucKEuduDOttpwCUCxSd-Ct8auzcg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

How to disable system check framework?

[Marcin Nowak]

Hi,

I need to upgrade project to Django 1.8 but the SystemCheck Framework 
bothers me.
It complains about thigs that should work, even if they are a little tricky.

I need to disable system checks designed for blogs and other simple sites. 
How can I do that?

Best Regards,
Marcin

-- 
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/66320218-db2c-4861-afdd-0592b0ba3861%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to disable system check framework?

[Carl Meyer]

> On Aug 4, 2015, at 9:18 AM, Marcin Nowak  wrote:
> 
> I need to upgrade project to Django 1.8 but the SystemCheck Framework bothers 
> me.
> It complains about thigs that should work, even if they are a little tricky.
> 
> I need to disable system checks designed for blogs and other simple sites. 
> How can I do that?

The third paragraph of the system checks documentation [1] links to [2].

Also, this is a question about using Django, not developing Django, so it 
belongs on the django-users mailing list, not here. 

Carl

[1] https://docs.djangoproject.com/en/1.8/topics/checks/
[2] 
https://docs.djangoproject.com/en/1.8/ref/settings/#std:setting-SILENCED_SYSTEM_CHECKS

-- 
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/5CA4CB28-D731-4E4C-82EF-80FCC2F1C47B%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.

Re: How to disable system check framework?

[Marcin Nowak]

Thanks, Carl. I know about silencing but I want to disable unwanted 
"feature". Working with Django is getting harder with every new version. 


On Tuesday, August 4, 2015 at 3:25:22 PM UTC+2, Carl Meyer wrote:
>
>
> > On Aug 4, 2015, at 9:18 AM, Marcin Nowak  > wrote: 
> > 
> > I need to upgrade project to Django 1.8 but the SystemCheck Framework 
> bothers me. 
> > It complains about thigs that should work, even if they are a little 
> tricky. 
> > 
> > I need to disable system checks designed for blogs and other simple 
> sites. How can I do that? 
>
> The third paragraph of the system checks documentation [1] links to [2]. 
>
> Also, this is a question about using Django, not developing Django, so it 
> belongs on the django-users mailing list, not here. 
>
> Carl 
>
> [1] https://docs.djangoproject.com/en/1.8/topics/checks/ 
> [2] 
> https://docs.djangoproject.com/en/1.8/ref/settings/#std:setting-SILENCED_SYSTEM_CHECKS

-- 
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/6bf13f68-a2ca-4c1d-95d7-314a10d95c10%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

View permissions to admin

[petr . dlouhy]

Hi,

4 months ago, I have implemented view permissions for Django admin and 
posted it under following ticket:
https://code.djangoproject.com/ticket/8936

The patch in my branch contains tests and documentation.

I am willing to give my time to make this commited to official Django 
branch. But I would need to get some commits, suggestions and advises from 
more expert Django developers.

Petr Dlouhý

-- 
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/a941655b-81be-4577-93e6-0ba5b3956e2c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: future of QuerySet.extra()?

[Shai Berger]

Hi,

On Tuesday 04 August 2015 03:28:03 Josh Smeaton wrote:
> On Tuesday, 4 August 2015 07:10:05 UTC+10, Shai Berger wrote:
> > On Monday 03 August 2015 10:27:14 Anssi Kääriäinen wrote:
> > > You can annotate raw SQL with expressions. I think the only case that
> > > can't be done with expressions is addition of extra tables to the query.
> > 
> > Also grouping over non-relations, if I am not mistaken.
> > 
> Can you explain/give an example of grouping over non relations? I'll see if
> I can translate that to expressions in their current form.
> 
The classic database aggregation examples involve aggregation over time: Sum 
of sales per quarter (which is, itself, a function over date); average 
temparature per month; etc. All these require group-by clauses which name 
(expressions over) columns which are not FKs.

There are many similar examples involving "enum columns" -- columns with a 
limited set of choices, where the choices are not instances of another model.

As far as I am aware, we can still not do these aggregates in the ORM,

Shai.

Re: future of QuerySet.extra()?

[Anssi Kääriäinen]

On Tuesday, August 4, 2015, Shai Berger  wrote:
>
> The classic database aggregation examples involve aggregation over time:
> Sum
> of sales per quarter (which is, itself, a function over date); average
> temparature per month; etc. All these require group-by clauses which name
> (expressions over) columns which are not FKs.
>
>
The following should work:

 
qs.annotate(quarter=Quarter('sold_date')).values('quarter').annotate(sum=Sum('amount'))

I recall some changes to how the group by expression is generated for
expressions. If I recall correctly the group by should have the expression
itself now, not the base columns of the expression.

There are many similar examples involving "enum columns" -- columns with a
> limited set of choices, where the choices are not instances of another
> model.


I'm not sure of this one.

 - 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/CALMtK1FqTkdmnXNYvjZ8U_QF9%2BWzrMCb1DDFQU5WB4SiKPX06g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: future of QuerySet.extra()?

[Josh Smeaton]

You're right about that. You can aggregate over custom expressions. For
aggregating over enums you should be able to use case expressions

On Wed, 5 Aug 2015 at 05:05 Anssi Kääriäinen  wrote:

> On Tuesday, August 4, 2015, Shai Berger  wrote:
>>
>> The classic database aggregation examples involve aggregation over time:
>> Sum
>> of sales per quarter (which is, itself, a function over date); average
>> temparature per month; etc. All these require group-by clauses which name
>> (expressions over) columns which are not FKs.
>>
>>
> The following should work:
>
>
>  
> qs.annotate(quarter=Quarter('sold_date')).values('quarter').annotate(sum=Sum('amount'))
>
> I recall some changes to how the group by expression is generated for
> expressions. If I recall correctly the group by should have the expression
> itself now, not the base columns of the expression.
>
> There are many similar examples involving "enum columns" -- columns with a
>> limited set of choices, where the choices are not instances of another
>> model.
>
>
> I'm not sure of this one.
>
>  - Anssi
>
> --
> 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/FojuU0syO8Y/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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CALMtK1FqTkdmnXNYvjZ8U_QF9%2BWzrMCb1DDFQU5WB4SiKPX06g%40mail.gmail.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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAPbDM0dLTZTBzZUcPPTY_4S9BympXtkm%3D%3DsNr1pZNYDxeauzMQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Setting up Django Over Apache Web-server

[Russell Keith-Magee]

Hi Mudassar,

If you're looking for help on how to use or deploy Django, you should post
to the django-users mailing list. This list is for discussing the
development of Django itself.

Yours,
Russ Magee %-)

On Tue, Aug 4, 2015 at 7:36 AM, Mudassar Hashmi <
mudassarziahash...@hotmail.com> wrote:

> Please help to upload django on apache web server with without terminal
> access to web server.
>
> Regards,
>
> Mudassar Hashmi
>
> --
> 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/COL126-W255BB734B46EC91F6C6D58C8770%40phx.gbl
> 
> .
> 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJxq84_0ZRoMSa6SBQPQwLj%3DdiBvYKC1A7HYgu6NzuLcA_3zRQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to disable system check framework?

[Josh Smeaton]

Your "scare quotes" for "feature" are really disappointing. Especially 
considering that the checks were hardcoded and couldn't be silenced prior 
to the "system check framework".

> Working with Django is getting harder with every new version.

If you want to turn off new features or extension points, then I'd imagine 
there'd be more work than for the regular user. Otherwise, I couldn't 
disagree more.

Anyhow, you want to turn off system checks for some reason. Here are some 
potential ways forward:

- Target the checks that are incorrectly spitting out errors or warnings, 
and fix those.
- Provide another setting "DISABLE_CHECKS" or something similar that will 
prevent checks running altogether (probably not ideal, new settings are 
hard to get into core, especially when the benefit here is still 
questionable).
- Provide a special value for the existing SILENCED_SYSTEM_CHECKS setting 
that causes all checks to be silenced.

You haven't really said much about the issue other than it bothers you. The 
main purpose of checks are for development - so it doesn't have any runtime 
or deployment time penalties. Perhaps if you took some time to justify why 
users other than yourself might want to disable the check framework, it'd 
be easier to start looking at solutions to problems.

Cheers


On Wednesday, 5 August 2015 01:16:21 UTC+10, Marcin Nowak wrote:
>
> Thanks, Carl. I know about silencing but I want to disable unwanted 
> "feature". Working with Django is getting harder with every new version. 
>
>
> On Tuesday, August 4, 2015 at 3:25:22 PM UTC+2, Carl Meyer wrote:
>>
>>
>> > On Aug 4, 2015, at 9:18 AM, Marcin Nowak  wrote: 
>> > 
>> > I need to upgrade project to Django 1.8 but the SystemCheck Framework 
>> bothers me. 
>> > It complains about thigs that should work, even if they are a little 
>> tricky. 
>> > 
>> > I need to disable system checks designed for blogs and other simple 
>> sites. How can I do that? 
>>
>> The third paragraph of the system checks documentation [1] links to [2]. 
>>
>> Also, this is a question about using Django, not developing Django, so it 
>> belongs on the django-users mailing list, not here. 
>>
>> Carl 
>>
>> [1] https://docs.djangoproject.com/en/1.8/topics/checks/ 
>> [2] 
>> https://docs.djangoproject.com/en/1.8/ref/settings/#std:setting-SILENCED_SYSTEM_CHECKS
>
>

-- 
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/14d4f121-2e75-4f35-b8ef-ced371060f5e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: View permissions to admin

[Josh Smeaton]

Hi Petr,

Thanks for working on that ticket. I'm probably not the person to be 
reviewing work in the admin, but here are a few ideas for getting your 
patch noticed.

1. Create a pull request against the Django repository. Even if it's not 
ready to be merged, a pull request makes it a lot easier to provide review 
and comment on your changes.
2. Provide a description of what your patch is aiming to do in the pull 
request comments. "view_permissions" for admin don't tell me a whole lot, 
why do we need view permissions? Answering that question will help review.

Writing to the mailing list here is also good, but having your code 
available as a PR makes it easier for people to jump from here to your code 
and provide feedback where it counts.

Regards,

On Wednesday, 5 August 2015 02:37:01 UTC+10, petr@auto-mat.cz wrote:
>
> Hi,
>
> 4 months ago, I have implemented view permissions for Django admin and 
> posted it under following ticket:
> https://code.djangoproject.com/ticket/8936
>
> The patch in my branch contains tests and documentation.
>
> I am willing to give my time to make this commited to official Django 
> branch. But I would need to get some commits, suggestions and advises from 
> more expert Django developers.
>
> Petr Dlouhý
>

-- 
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/4b47b345-dd4c-44c6-ba81-04e8edf6e3dc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.