date:20151120

Re: "Project" vs "App"

2015-11-20 Thread Aymeric Augustin

Hello Thomas,

Thanks for bringing this up. There’s definitely some room for improving the 
documentation — I know because I wrote it.

In terms of organization, I’d rather discuss how each topic (settings, models, 
etc.) relates to projects and apps than talk first about projects, then about 
apps. Otherwise there’s some repetition between the two sections and it’s 
harder to compare.

Your proposal touches many topics and was a good base for brainstorming. My 
thoughts below.


> Project
> ==

> A project is a container for apps.
=> Yes.

> It contains only settings, no database models.
=> It’s also considered a good practice to put templates and static files at 
the project level (rather than spread across apps, even though Django supports 
it for pluggable applications. I would focus on saying that “models can only 
live within applications”. It’s part of the design of the ORM.

> Since it contains no database models it does not contain database schema 
> migrations.
> It can contain migrations which fill a database with project specific data.
=> You’re going to confuse people to no end if you evoke MIGRATION_MODULES, a 
highly advanced and tricky concept, in an introductory document. I wouldn’t 
discuss migrations at all here. Stick with models.

=> You could say something about fixtures, which can live either at the project 
or app level. However the argument for putting them at project level is as 
strong as for templates and static files. I’m not sure you could say something 
sufficiently clear to enlighten readers.

> It is common that there is only one production installation of one project.
=> You could also say that a project often corresponds to a website.

> It is common to have several stages (dev, test, prod) for one project.
=> I usually say “environment”, not “stage”.

> A project might contain a sitecustomize.py
=> There’s a consensus for saying that this is an uncommon technique in the 
Django world, albeit a legitimate one. Better not mention it in an introduction.


> App
> ===
> An app can have models, views and code.
=> And plenty of other things :-) migrations, translations, URLs, templates, 
template tags, static files, etc.

> It should be re-usable.
=> I’d rather say “As much as possible, it should encapsulate an aspect of a 
project. Some apps are reusable, which means they can be shared between various 
projects. Reusable apps, sometimes called pluggable apps, are the most common 
way to distribute Django-related libraries."

> An app can depend on other apps.
> It must not depend on a project.
=> Technically, almost every app depends on a project in the sense that they 
require proper configuration of the project. This needs careful wording to 
avoid confusion.

> An app can contain a settings.py for testing, but it contains no settings on 
> its own.
=> This is correct but I’m not sure it’ll be useful to people who have barely 
heard about reusable apps or unit testing, let alone how both interact with 
Django’s requirement to have a global settings module. They are the people an 
introduction to project vs. app targets. I would skip this topic.

> It should have instructions which settings are needed to get the app running 
> in a project.
=> Yes. This goes with the discussion of how projects depend on apps.

> A app must not contain a sitecustomize.py.
=> As above.


This is not as easy to explain as it might seem for someone familiar with the 
concept…

I hope this helps putting together a patch! I’m happy to review or further 
discuss a proposal.

Best regards,

-- 
Aymeric.



> On 19 nov. 2015, at 10:54, guettli  wrote:
> 
> I created a ticket to find a better definition of "Project" vs "App"
> 
> https://code.djangoproject.com/ticket/25748
> 
> I am happy since Tim Graham accepted it.
> 
> Here are the current docs: 
> https://docs.djangoproject.com/en/1.8/ref/applications/#projects-and-applications
> 
> Here is my view of Project" vs "App". It would be nice to find a consensus 
> and update the docs.
> 
> Project
> ==
> A project is a container for apps.
> It contains only settings, no database models.
> Since it contains no database models it does not contain database schema 
> migrations.
> It can contain migrations which fill a database with project specific data.
> It is common that there is only one production installation of one project.
> It is common to have several stages (dev, test, prod) for one project.
> A project might contain a sitecustomize.py
> 
> App
> ===
> An app can have models, views and code.
> It should be re-usable.
> An app can depend on other apps.
> It must not depend on a project.
> An app can contain a settings.py for testing, but it contains no settings on 
> its own.
> It should have instructions which settings are needed to get the app running 
> in a project.
> A app must not contain a sitecustomize.py.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
>

Re: "Project" vs "App"

2015-11-20 Thread Asif Saifuddin

Without the part of sitecustomize agree with the other parts.

+ there should be distinction between projects app and install apps


Reagards

On Thursday, November 19, 2015 at 3:54:40 PM UTC+6, guettli wrote:
>
> I created a ticket to find a better definition of "Project" vs "App"
>
> https://code.djangoproject.com/ticket/25748
>
> I am happy since Tim Graham accepted it.
>
> Here are the current docs: 
> https://docs.djangoproject.com/en/1.8/ref/applications/#projects-and-applications
>
> Here is my view of Project" vs "App". It would be nice to find a consensus 
> and update the docs.
>
> Project
> ==
> A project is a container for apps.
> It contains only settings, no database models.
> Since it contains no database models it does not contain database schema 
> migrations.
> It can contain migrations which fill a database with project specific data.
> It is common that there is only one production installation of one project.
> It is common to have several stages (dev, test, prod) for one project.
> A project might contain a sitecustomize.py
>
> App
> ===
> An app can have models, views and code.
> It should be re-usable.
> An app can depend on other apps.
> It must not depend on a project.
> An app can contain a settings.py for testing, but it contains no settings 
> on its own.
> It should have instructions which settings are needed to get the app 
> running in a project.
> A app must not contain a sitecustomize.py.
>

-- 
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/eda9c93c-96ff-4c18-a144-3b15c4e17f86%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: __ne, #5763

2015-11-20 Thread James Bennett

8 years later, I still think we should figure out how to make exclude() do
what people expect it to do, rather than implement another lookup type that
overlaps with it.

On Fri, Nov 20, 2015 at 7:27 PM, Aaron C. de Bruyn 
wrote:

> With all due respect, looking through the ticket and reading responses
> shows me that the 'pro' side has good use cases for __ne, and the 'con'
> side basically says "use exclude" or "a core committer close the ticket,
> stop opening it" with no good reasoning or rationale behind it.
>
> -A
>
> On Fri, Nov 20, 2015 at 5:22 PM, Marcin Nowak 
> wrote:
>
>>
>>
>> On Friday, November 20, 2015 at 8:37:02 PM UTC+1, Carsten Fuchs wrote:
>>>
>>> sorry if this is a stupid question, but after having read
>>> https://code.djangoproject.com/ticket/5763 and the discussions linked
>>> from it, why should __ne not be implemented?
>>>
>>>
>> Because Django ORM __ne SQLAlchemy.
>>
>> BR,
>> 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/5cb90d5f-8683-4a34-9c15-f06bb23e6eee%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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAEE%2BrGopLJaRL6%3D8uafjBoAjkcFO9DuRaDXeBD6M6oWNFoADiQ%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/CAL13Cg-CLimLgNAFMc06YtQ%3Dut3%2BbZ9F87r2sr%3DmyBBEXPE2Qg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: __ne, #5763

2015-11-20 Thread Aaron C. de Bruyn

With all due respect, looking through the ticket and reading responses
shows me that the 'pro' side has good use cases for __ne, and the 'con'
side basically says "use exclude" or "a core committer close the ticket,
stop opening it" with no good reasoning or rationale behind it.

-A

On Fri, Nov 20, 2015 at 5:22 PM, Marcin Nowak 
wrote:

>
>
> On Friday, November 20, 2015 at 8:37:02 PM UTC+1, Carsten Fuchs wrote:
>>
>> sorry if this is a stupid question, but after having read
>> https://code.djangoproject.com/ticket/5763 and the discussions linked
>> from it, why should __ne not be implemented?
>>
>>
> Because Django ORM __ne SQLAlchemy.
>
> BR,
> 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/5cb90d5f-8683-4a34-9c15-f06bb23e6eee%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAEE%2BrGopLJaRL6%3D8uafjBoAjkcFO9DuRaDXeBD6M6oWNFoADiQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: __ne, #5763

2015-11-20 Thread Marcin Nowak



On Friday, November 20, 2015 at 8:37:02 PM UTC+1, Carsten Fuchs wrote:
>
> sorry if this is a stupid question, but after having read 
> https://code.djangoproject.com/ticket/5763 and the discussions linked 
> from it, why should __ne not be implemented?
>
>
Because Django ORM __ne SQLAlchemy. 

BR,
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/5cb90d5f-8683-4a34-9c15-f06bb23e6eee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

__ne, #5763

2015-11-20 Thread Carsten Fuchs

Hi all,

sorry if this is a stupid question, but after having read 
https://code.djangoproject.com/ticket/5763 and the discussions linked from 
it, why should __ne not be implemented?

Without __ne, I'm experiencing the same problems that asmoore82 described 
at https://code.djangoproject.com/ticket/5763#comment:23
That is, afaics, some queries cannot be formulated without __ne, as 
exclude() is not an equivalent. Or am I missing or misunderstanding 
something?
I can live with the existing work-arounds, so I'm mostly curious.   :-)

Best regards,
Carsten

-- 
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/0b0cbc2d-9fb1-4f74-a994-5598c2590b7d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Form field labels change proposal

2015-11-20 Thread Tim Graham

Looks easy enough. I was going to write, "Seems to me that there's more 
complexity in a deprecation path that requires a temporary opt-in setting 
rather than simply making the backwards incompatible change. Unless I 
missed something, adding CSS like that shouldn't cause problems for any 
apps maintaining compatibility with older versions of Django." but then I 
thought of a different case where it could be trickier to upgrade: 
developers who are specifying label='lower string' in some places to 
workaround the current behavior (but still want uppercased labels 
everywhere else). I guess the solution would be to use the text-transform 
rule you mentioned and another CSS rule targeting all labels IDs that you 
want to remain lowercased.

I'd like other opinions about whether or not a deprecation seems helpful 
for this. Personally, I'd rather just fix my CSS when upgrading rather than 
fix my CSS *and* add a setting for a few Django versions to silence the 
deprecation. I guess some people might like a few Django versions to update 
their CSS though (also we promised to try to provide fairly seamless 
upgrades from one LTS to the next).

On Friday, November 20, 2015 at 11:38:53 AM UTC-5, Sergei Maertens wrote:
>
> In 
> https://github.com/django/django/blob/master/django/contrib/admin/static/admin/css/forms.css#L31
>  
> ,
>  
> after
> label {
>font-weight: normal;
>color:#666;
>font-size:13px;
> }
>
> you would add
> label::first-letter {
>text-transform: capitalize;
> }
>
> (see https://css-tricks.com/almanac/selectors/f/first-letter/)
>
> text-transform: capitalize on the label itself would capitalize all words, 
> which is not wanted. The ::first-letter pseudo-selector is supported on all 
> browsers, for IE 8 and lower you need a sigle colon instead of a double 
> colon.
>
>
> On Thursday, November 19, 2015 at 11:23:48 PM UTC+1, Tim Graham wrote:
>>
>> I'd like to see the admin's CSS updated under the assumption that this 
>> change moves forward to better understand the extent of changes that would 
>> be required from Django users to maintain the current behavior.
>>
>> On Thursday, November 19, 2015 at 4:52:57 PM UTC-5, Sergei Maertens wrote:
>>>
>>> Yes, I've thought about a setting as well briefly but quickly discarded 
>>> it because it would be 'yet another setting'. But this one would ofcourse 
>>> be temporarily, and if that's been applied successfully in the past, then 
>>> that's probably the best way to tackle this.
>>>
>>> I'd be happy to write the patch for this myself if no objections turn up.
>>>
>>> On Thursday, November 19, 2015 at 10:49:49 PM UTC+1, Tim Graham wrote:

 The best solution I can think of at the moment would be a setting 
 allowing users to opt-in to the new behavior which would then silence the 
 warning. That leaves you with a defunct setting once the deprecation 
 period 
 completes. That's basically how SessionAuthenticationMiddleware worked 
 when we decided to require it.

 On Thursday, November 19, 2015 at 4:13:40 PM UTC-5, Sergei Maertens 
 wrote:
>
> Good catch.
>
> I'm not sure, haven't there been similar cases in the past? First 
> thing I can think of is using naive datetimes when timezone-support is 
> enabled, and then you get a warning for each naive datetime you use, but 
> that's of course different then a DeprecationWarning.
>
> It's probably not best practice, but maybe it could be tracked with a 
> module-level flag/constant, to check if the warning has been emited or 
> not, 
> ensuring that it gets only emited once during the lifetime of a thread?
>
> On Thursday, November 19, 2015 at 7:27:18 PM UTC+1, Tim Graham wrote:
>>
>> How would a developer acknowledge/silence that deprecation warning? 
>> It seems to me that if it's emitted for every form field in a project 
>> that's not really going to be helpful.
>>
>> On Wednesday, November 11, 2015 at 11:47:46 AM UTC-5, Sergei Maertens 
>> wrote:
>>>
>>> I think I would start with locally creating a wrapper capfirst that 
>>> is only called in the referenced line and 
>>> https://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L2069
>>>  
>>> (missed that one in the previous post) and possible other ocurrences. 
>>> Emit 
>>> a PendingDeprecationWarning, something along the lines of
>>>
>>> def deprecated_capfirst(value):
>>> warnings.warn(
>>> "form field labels generated from model field 'verbose_name' 
>>> will no longer automatically be capitalized",
>>> PendingDeprecationWarning, stacklevel=2
>>> )
>>> return capfirst(value)
>>>
>>> and

Re: Form field labels change proposal

2015-11-20 Thread Sergei Maertens

In 
https://github.com/django/django/blob/master/django/contrib/admin/static/admin/css/forms.css#L31,
 
after
label {
   font-weight: normal;
   color:#666;
   font-size:13px;
}

you would add
label::first-letter {
   text-transform: capitalize;
}

(see https://css-tricks.com/almanac/selectors/f/first-letter/)

text-transform: capitalize on the label itself would capitalize all words, 
which is not wanted. The ::first-letter pseudo-selector is supported on all 
browsers, for IE 8 and lower you need a sigle colon instead of a double 
colon.


On Thursday, November 19, 2015 at 11:23:48 PM UTC+1, Tim Graham wrote:
>
> I'd like to see the admin's CSS updated under the assumption that this 
> change moves forward to better understand the extent of changes that would 
> be required from Django users to maintain the current behavior.
>
> On Thursday, November 19, 2015 at 4:52:57 PM UTC-5, Sergei Maertens wrote:
>>
>> Yes, I've thought about a setting as well briefly but quickly discarded 
>> it because it would be 'yet another setting'. But this one would ofcourse 
>> be temporarily, and if that's been applied successfully in the past, then 
>> that's probably the best way to tackle this.
>>
>> I'd be happy to write the patch for this myself if no objections turn up.
>>
>> On Thursday, November 19, 2015 at 10:49:49 PM UTC+1, Tim Graham wrote:
>>>
>>> The best solution I can think of at the moment would be a setting 
>>> allowing users to opt-in to the new behavior which would then silence the 
>>> warning. That leaves you with a defunct setting once the deprecation period 
>>> completes. That's basically how SessionAuthenticationMiddleware worked 
>>> when we decided to require it.
>>>
>>> On Thursday, November 19, 2015 at 4:13:40 PM UTC-5, Sergei Maertens 
>>> wrote:

 Good catch.

 I'm not sure, haven't there been similar cases in the past? First thing 
 I can think of is using naive datetimes when timezone-support is enabled, 
 and then you get a warning for each naive datetime you use, but that's of 
 course different then a DeprecationWarning.

 It's probably not best practice, but maybe it could be tracked with a 
 module-level flag/constant, to check if the warning has been emited or 
 not, 
 ensuring that it gets only emited once during the lifetime of a thread?

 On Thursday, November 19, 2015 at 7:27:18 PM UTC+1, Tim Graham wrote:
>
> How would a developer acknowledge/silence that deprecation warning? It 
> seems to me that if it's emitted for every form field in a project that's 
> not really going to be helpful.
>
> On Wednesday, November 11, 2015 at 11:47:46 AM UTC-5, Sergei Maertens 
> wrote:
>>
>> I think I would start with locally creating a wrapper capfirst that 
>> is only called in the referenced line and 
>> https://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L2069
>>  
>> (missed that one in the previous post) and possible other ocurrences. 
>> Emit 
>> a PendingDeprecationWarning, something along the lines of
>>
>> def deprecated_capfirst(value):
>> warnings.warn(
>> "form field labels generated from model field 'verbose_name' 
>> will no longer automatically be capitalized",
>> PendingDeprecationWarning, stacklevel=2
>> )
>> return capfirst(value)
>>
>> and replace the capfirst with deprecated_capfirst ofcourse. At the 
>> same time, in the admin the CSS for labels can be added to 
>> text-transform 
>> them to capitalize.
>>
>> In the next Django version this becomes loud, and in the next+1 
>> version it is effectively removed.
>>
>> As soon as the PendingDeprecation is added, the entry should be added 
>> to the docs with example CSS to make your own templates/styling 
>> capitalize 
>> the labels - and/or mention the `capfirst` template filter.
>>
>> Thoughts?
>>
>>
>> On Wednesday, November 11, 2015 at 5:32:57 PM UTC+1, Tim Graham wrote:
>>>
>>> How do you envision putting this through a deprecation cycle?
>>>
>>> On Wednesday, November 11, 2015 at 10:59:46 AM UTC-5, Sergei 
>>> Maertens wrote:

 This is a proposal to change how Django generates form field labels 
 from model fields. Currently, `capfirst` is called on 
 `field.verbose_name` 
 (see 
 https://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L872
  
 ).
  
 This behaviour has been around since pretty much forever and makes 
 sense.

 However, this affects what you put down in your translations - if a 
 lowercased

Re: "Project" vs "App"

2015-11-20 Thread Remco Gerlich

So it seems a sitecustomize.py is something internal to your company, and
you are proposing to document this for Django in general. So that shouldn't
be in there, right?

Also, although circular dependencies are probably a sign of a less than
perfect design, reality isn't perfect and they sometimes happen. Django
allows them just fine, so its docs should not say that some kinds of
dependencies are not allowed. They are.

Also, projects can be apps themselves. You can have your project's package
in INSTALLED_APPS, and I believe that that is in fact a pretty common
pattern. In particular, in the situation that you describe where you test
an app using its own settings.py, you are using the app as a project and an
app at the same time.

Also apps *may* be re-usable, and if they are then it is nice if they have
instructions for settings somewhere, but I don't see that as part of an
explanation of what an app is.

The current docs ( https://docs.djangoproject.com/en/dev/ref/applications/
) say "A project is defined primarily by a settings module." and "The term
*application* describes a Python package that provides some set of
features. Applications may be reused in various projects."

And I feel that getting more specific than that means that you probably
forget uses case that people use in production.

To me, apps are equivalent to modules. There are many reasons to divide
code into modules (your original module becomes too large, you want to
reuse parts of your code, you want to make dependencies explicit, etc). For
instance, you may want to split your models module, or your urls module, or
your views module. It usually makes sense to divide them together, because
they are often coupled. So that becomes an app.

Greetings,
Remco Gerlich

On Thu, Nov 19, 2015 at 10:54 AM, guettli 
wrote:

> I created a ticket to find a better definition of "Project" vs "App"
>
> https://code.djangoproject.com/ticket/25748
>
> I am happy since Tim Graham accepted it.
>
> Here are the current docs:
> https://docs.djangoproject.com/en/1.8/ref/applications/#projects-and-applications
>
> Here is my view of Project" vs "App". It would be nice to find a consensus
> and update the docs.
>
> Project
> ==
> A project is a container for apps.
> It contains only settings, no database models.
> Since it contains no database models it does not contain database schema
> migrations.
> It can contain migrations which fill a database with project specific data.
> It is common that there is only one production installation of one project.
> It is common to have several stages (dev, test, prod) for one project.
> A project might contain a sitecustomize.py
>
> App
> ===
> An app can have models, views and code.
> It should be re-usable.
> An app can depend on other apps.
> It must not depend on a project.
> An app can contain a settings.py for testing, but it contains no settings
> on its own.
> It should have instructions which settings are needed to get the app
> running in a project.
> A app must not contain a sitecustomize.py.
>
> --
> 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/1a7e8d69-1970-4b07-b820-90c4d652486b%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFAGLK3MwcHzxJsU06G79Vnbuf-4z0pHFJKx_qSLekYNHu%2B1Yw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: "Project" vs "App"

2015-11-20 Thread guettli



Am Donnerstag, 19. November 2015 15:12:16 UTC+1 schrieb Collin Anderson:
>
> What's a sitecustomize.py? :)
>


This module is automatically imported during initialization if the 
interpreter.

We use it to:

 - sort sys.path.
 - monkey patching. During the Update from Django 1.6 to 1.7 we added an 
empty django.setup() to make code work on 1.6 and 1.7

See https://docs.python.org/2/library/site.html



 

> I think apps _can_/_may_ be reusable. I have plenty of non-reusable apps. 
> Why should they be reusable?
>

Yes, you are right. In my context we focus on re-usablity. We create 
software which gets used by
several customers (each running in their intranet). If you have only one 
plattform, then the
"should" is too strong. 
 

> I think apps _should_ not depend on a project.
>
>
If an app depends on the project there is a circular dependency. This 
should be avoided.
See https://en.wikipedia.org/wiki/Circular_dependency

That's why I vote for "An app must not depend on a project".

Thank you Collin for your feedback. I still hope some other people join 
this thread.

Regards,
  Thomas 

 

>
> On Thu, Nov 19, 2015 at 4:54 AM, guettli  > wrote:
>
>> I created a ticket to find a better definition of "Project" vs "App"
>>
>> https://code.djangoproject.com/ticket/25748
>>
>> I am happy since Tim Graham accepted it.
>>
>> Here are the current docs: 
>> https://docs.djangoproject.com/en/1.8/ref/applications/#projects-and-applications
>>
>> Here is my view of Project" vs "App". It would be nice to find a 
>> consensus and update the docs.
>>
>> Project
>> ==
>> A project is a container for apps.
>> It contains only settings, no database models.
>> Since it contains no database models it does not contain database schema 
>> migrations.
>> It can contain migrations which fill a database with project specific 
>> data.
>> It is common that there is only one production installation of one 
>> project.
>> It is common to have several stages (dev, test, prod) for one project.
>> A project might contain a sitecustomize.py
>>
>> App
>> ===
>> An app can have models, views and code.
>> It should be re-usable.
>> An app can depend on other apps.
>> It must not depend on a project.
>> An app can contain a settings.py for testing, but it contains no settings 
>> on its own.
>> It should have instructions which settings are needed to get the app 
>> running in a project.
>> A app must not contain a sitecustomize.py.
>>
>> -- 
>> 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-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@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/1a7e8d69-1970-4b07-b820-90c4d652486b%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/188ce7e0-73a3-45f4-81d6-3acaa7bea7ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Question] Many-To-Many query where only pk is returned

2015-11-20 Thread Anssi Kääriäinen

We din't currently do join trimming from the beginning of the query's
tables, only from the end of the tables.

Fixing this issue only doesn't seem worth it, as the current join trimmig
code can't be adapted to handle trimming from the beginning of the query's
tables. But we might be able to trim any non-necessary table from the query
in the compiler stage. If we were able to do that, then there might be a
point in implementing that. I know we sometimes include non-necessary
tables in the query for example in multitable inheritance scenarios.

 - Anssi

On Thursday, November 19, 2015, Cristiano Coelho 
wrote:

> You are right. I believe an optimization like this would probably help
> just a few people, as only fetching data from the intermediary table is a
> rare thing. But if it is an easy change, which improves performance, why
> not? However I think the change is quite complicated.
>
> El jueves, 19 de noviembre de 2015, 11:51:51 (UTC-3), charettes escribió:
>>
>> Hi Cristiano,
>>
>> If I get it correctly you'd like m2m querying to start with the
>> intermediary (FROM) table and JOIN the referenced one only if more fields
>> than the primary key are selected.
>>
>> class Book(models.Model):
>> name = models.CharField(max_length=100)
>>
>> class Author(models.Model):
>> books = models.ManyToMany(Book)
>>
>> author = Author.objects.get(pk=1)
>> author.books.values_list('pk')
>>
>> Would result in the following query:
>> SELECT book_id FROM author_books WHERE author_id = 1;
>>
>> Instead of:
>> SELECT id FROM book JOIN author_books ON (book.id =
>> author_books.book_id) WHERE author_id = 1;
>>
>> I think this is a sensible optimization but I wonder about its
>> feasibility. It looks like the `pk` reference would require some special
>> handling to reference `book_id` since it's not actually a primary key on
>> the intermediate table.
>>
>> Simon
>>
>> Le mercredi 18 novembre 2015 19:41:22 UTC-5, Cristiano Coelho a écrit :
>>>
>>> Hello there,
>>>
>>> Lets say I have these two models (sorry about the spanish names!) (
>>> Django 1.8.6 and MySQL backend )
>>>
>>> class Especialidad(models.Model):
>>> nombre = models.CharField(max_length=250, blank=False, unique=True)
>>>
>>>
>>>
>>> class Usuario(AbstractBaseUser):
>>> permisosEspecialidad = models.ManyToManyField("Especialidad", 
>>> blank=True)
>>>
>>> Let u be some Usuario instance, and the following query:
>>>
>>> u.permisosEspecialidad.all().values_list('pk',flat=True)
>>>
>>> The actual printed query is:
>>>
>>> SELECT `samiBackend_especialidad`.`id`
>>> FROM `samiBackend_especialidad`
>>> INNER JOIN `samiBackend_usuario_permisosEspecialidad` ON ( 
>>> `samiBackend_especialidad`.`id` = 
>>> `samiBackend_usuario_permisosEspecialidad`.`especialidad_id` )
>>> WHERE `samiBackend_usuario_permisosEspecialidad`.`usuario_id` = 8
>>>
>>> As my understanding, since I'm only selecting the id field which is already 
>>> present in the intermediary table (and is also a FK), the actual join is 
>>> redundant, as I have all the info I need in this case.
>>>
>>> So the query could work like this
>>>
>>> SELECT `samiBackend_usuario_permisosEspecialidad`.`especialidad_id`
>>> FROM  `samiBackend_usuario_permisosEspecialidad`
>>> WHERE `samiBackend_usuario_permisosEspecialidad`.`usuario_id` = 8
>>>
>>>
>>> I guess this works this way because this particular case might be hard to 
>>> detect or won't be compatible with any additional query building, however, 
>>> for ForeignKey relations, this optimization is already done (If you select 
>>> the primary key from the selected model only, it wont add a join)
>>>
>>> What would be the complications to implement this? Would it worth the 
>>> effort?
>>>
>>>
>>> --
> 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/f96c5d2f-3655-461f-8534-de8622cd284d%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,

Re: "Project" vs "App"

Re: "Project" vs "App"

Re: __ne, #5763

Re: __ne, #5763

Re: __ne, #5763

__ne, #5763

Re: Form field labels change proposal

Re: Form field labels change proposal

Re: "Project" vs "App"

Re: "Project" vs "App"

Re: [Question] Many-To-Many query where only pk is returned

11 matches

Site Navigation

Mail list logo

Footer information