Converting ModelAdmin system checks to run against instances rather than the class

[Malcolm Box]

Hi,

Raising this here as suggested by Tim on this 
bug: https://code.djangoproject.com/ticket/25374, with discussion also on 
django users 
here: https://groups.google.com/forum/#!topic/django-users/lsDP5oUWOsw

The underlying bug is that ModelAdmin checks are run against the class not 
the instance - which means that checks can fail when the code actually 
works. This sort of false positive feels bad to me.

The proposed PR changes the ModelAdmin checks to validating the created 
instance that will be registered rather than the ModelAdmin class itself. 
This mirrors how Django actually uses the ModelAdmin objects, and means 
that validation checks that previously threw false positives now pass.

Does this change make sense, or is there something subtle that I'm missing? 
More broadly, am I right in thinking that false-positive system check 
errors are a bad thing, and so we should aim to minimise/eliminate them, 
even at the cost of potential false negatives?

Cheers,

Malcolm




-- 
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/411901cb-7e72-4a94-99ef-8d6cbc24f4d6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ticket #23242 -- Approximate date_hierarchy

[Gavin Wahl]

The enum seems fine. Where should it be defined? Should the docs mention 
the integer values at all, or are you required to use the enum?

I don't think setting date_hierarchy to a tuple is any cleaner.

On Monday, August 31, 2015 at 12:54:21 PM UTC-6, Tim Graham wrote:
>
> This seems okay at first glance, though I wonder if an enum-like object 
> might be better than magic int/boolean values. Something like:
>
> class ApproximateWith(object):
> NONE = 0
> YEARS = 1
> MONTHS = 2
> DAYS = 3
>
> Do you think a separate ModelAdmin attribute better than allowing 
> something like:
>
> date_hierarchy = ('pub_date', ApproximateWith.YEARS)
>
> Values that can be string or tuple have contributed to bugs in the past, 
> but I thought it might be worth proposing.
>
> On Saturday, August 29, 2015 at 4:50:20 PM UTC-4, Gavin Wahl wrote:
>>
>> I'm going to fix ticket #23242 by adding an option to approximate the 
>> date_hierarchy options instead of calculating them exactly. The 
>> implementation is straightforward but I'm not sure what the interface 
>> should be. 
>>
>> The basic idea is instead of doing `SELECT DISTINCT date_trunc('year', 
>> created_at) FROM table`, then a date_trunc('month', created_at) to get the 
>> list of months, and so on, you can find the range with `SELECT 
>> date_trunc('year', max(created_at)), date_trunc('year', min(creeated_at))` 
>> and just assume that every year/month/day in between is filled in.
>>
>> How should this feature be enabled? Should it be possible to approximate 
>> the year list, but once you've selected the year switch to exact? I'm 
>> thinking something like:
>>
>> - approximate_date_hierarchy = False # default
>> - approximate_date_hierarchy = 1 # approximate years only
>> - approximate_date_hierarchy = 2 # approximate months and years
>> - approximate_date_hierarchy = 3 or True # approximate days, months, and 
>> years
>>
>>

-- 
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/194534a9-c3e5-4b58-ae1f-7f079b70cd24%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to document the error on trying to import django in python 3.4.

[Tim Graham]

I created a ticket: https://code.djangoproject.com/ticket/25376#ticket

You can read about how to get started contributing to Django in our docs: 
https://docs.djangoproject.com/en/dev/internals/contributing/

If you have any trouble, #django-dev is a good place to ask questions. 
Thanks!

On Thursday, September 10, 2015 at 9:15:01 AM UTC-4, Anjul Tyagi(geety) 
wrote:
>
> Yes, this is a perfect solution to this issue. But how do we proceed with 
> it ?
>
> Sorry, but I am new to django contribution !
>

-- 
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/2790ee19-7e07-45fd-be16-6c542fe28552%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ability to migrate other applications

[Emmanuelle Delescolle]

As this thread is most likely leading to a dead-end, let me try to close it 
by summarizing it:

Original proposal:
- adding a property to the current migration class to make it more 
extendable

Idea behind the proposal:
- being able to move the migrations generated in my venv when running 
makemigrations to a location under my repository without having to create 
my own Migration class which is mostly a copy-paste from Django's


Tim:
Thanks for suggesting copying existing migrations to another directory and 
using MIGRATION_MODULES. Although I really don't believe this is the answer 
for me as it sounds very error-prone and not very DRY (even if in this case 
I would be repeating somebody else and not myself).


Shai:
You feel strongly against this code as it subverts the whole idea behind 
migrations.
However you would enjoy this feature if it was called "project migrations" 
instead and, maybe, eventually, (if I understand the name of the feature 
correctly) if the feature was automated rather than manual (project 
migrations created directly inside the project instead of having to move 
them yourself and add the extra line in it)


Shai and Markus:
You are both very concerned about multiple leaf migration trees and about 
the fact that those leaf migrations might clash with each other.
After deeper thinking, this concern is probably more than legitimate but 
has, also probably, very little to do with the current proposal. If running 
makemigrations creates a new migration for an app you didn't write, it will 
end-up being a leaf migration independent of whether you leave it in your 
venv or are able to move it to your project and exposes you to the "clash" 
risks all the same.


Markus:
The idea of having several migration modules for the same app might be a 
good idea, although as I am currently living in a country being roughly 
slightly smaller than the largest cities on the global but, at the same 
time, supporting 3 official languages, creating an extra migration module 
for each app I install which's data needs translation doesn't sound very 
appealing to me. (more on how modeltranslation does it the wrong way here 
under)


Marten:
I am sorry but this proposal or any of this derivatives is unlikely to 
solve your username field length migration problem. If this field is your 
only trouble, you are probably better off using Tim's solution


About modeltranslation:
I, personally, am not too found of apps using contribute_to_class either so 
if anyone knows of an app which allows me to have translations for 
user-generated content living in my database (as those are translations for 
content from the database) which is pluggable on third party apps and 
doesn't require an extra join on (almost) every query, please let me know, 
I've been looking for such an app for a while. In the meantime, I'll keep 
using modeltranslation however "wrong" it might do things as it's pretty 
good at filling my personal expectations.


Thank you all for your time, I'll go back to copy-pasting now.
Cheers,
Emma

-- 
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/c754128c-6ab2-4021-9d16-b273be82b9ec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ability to migrate other applications

[Shai Berger]

On Wednesday 09 September 2015 16:35:16 Markus Holtermann wrote:
> On Wednesday, September 9, 2015 at 9:21:43 PM UTC+10, Shai Berger wrote:
> > On 9 בספטמבר 2015 13:29:58 GMT+03:00, Marten Kenbeek  > >
> > >The order of migrations within a single app is fixed.
> > 
> > No, actually it isn't. It is only constrained by dependencies. 
> 
> No, they do ensure some sort of deterministic behavior. Migrations are
> sorted by their fully qualified name (tuple of (app_label,
> migration_name)):
> https://github.com/django/django/blob/master/django/db/migrations/graph.py
> #L64
> 

A) This is an implementation detail, not part of the contract AFAIK. It was 
added because determinism is generally good. It was never intended to affect 
correctness, and 
B) More importantly -- it does not add dependencies, meaning, the code treats 
the situations where migrations were executed out of this ordering as valid 
(as long as no explicit dependencies are violated).

Two migrations affecting the same field, without an explicit ordering between 
them (directly or indirectly), are a bug, whether they are in the same app or 
not in the same app.

> This behavior is enough for a 3rd party app to destroy the results of your
> own migration or the other way round.
> 
> Consider a.1 <-- a.2 <-- b.1 where b.1 makes changes to the app a. When the
> author of app a add another migration a.3 (a.1 <-- a.2 <-- (a.3, b.1)) the
> resulting order in which migrations are applied will be a.1, a.2, a.3, b.1.
> However, on an existing database, a.3 will be run after b.1, resulting in a
> non-deterministic order in which migrations for the same app are being
> applied.
> 

Right. Now consider the same setting, except that b.1 is named a.2a (because 
more than one developer is working on this app). So we have:
a.1 <-- a.2 <-- (a.2a, a.3)

Nothing bad will happen, because as soon as the merge is done which gets a.2a 
and a.3 together in the same codebase, validation will cry foul and you'll 
need to sort things out manually and possibly add a merge migrartion. However, 
if you do add that merge migration (a,4) without realizing the problem, you 
get exactly where you were -- the actual resulting database depends on the 
order in which migrations happened historically.

This is all just strengthening my earlier point: Merge migrations' main 
contribution, currently, is to help with validation of possibly-conflicting 
migrations (their existence also probably allows some simplifications in the 
autogenerator). This is a very good mechanism, identifying the problems very 
early. However, they have a limitation: Validation only happens for migrations 
within the app. I think if model a.A has a fk to b.B and app b suddenly adds 
migrations changing B's pk from int to uuid we're already in trouble, for 
example. So, an improvement of the validations may be in order, and if we use 
a different mechanism (e.g. checking affected fields), perhaps this feature 
will 
become more palatable.

On Wednesday 09 September 2015 13:02:56 Emmanuelle Delescolle wrote:
> A "project" is just a module, so if you create a "migrations" directory, 
> add an __init__.py inside it and add it to your INSTALLED_APPS, you can 
> start placing migrations inside it.

Right. But, as Markus hinted, project-wide migrations should not be treated as 
just migrations in another module. As a trivial example -- for your sanity, if 
you're adding a project-level migration, you probably want it to depend on the 
last migration in every app at that time (other apps, as well as, of course, 
the project app itself). And there are many other similar considerations.

Shai.

Re: Proposal to document the error on trying to import django in python 3.4.

[Anjul Tyagi(geety)]

Yes, this is a perfect solution to this issue. But how do we proceed with 
it ?

Sorry, but I am new to django contribution !

-- 
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/d17491e2-5676-4387-8d5f-983a7ec9925a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to document the error on trying to import django in python 3.4.

[Anjul Tyagi(geety)]

Yes, that's the perfect solution to this problem.
How do we proceed with it then, as I am new to contributing to Django?
-Anjul

On Thursday, 10 September 2015 00:55:27 UTC+5:30, Tim Graham wrote:
>
> I think a better use of time could be to update the docs to more strongly 
> recommend virtualenv and discourage the use of `sudo pip install`.
>
> On Wednesday, September 9, 2015 at 10:17:48 AM UTC-4, Anjul Tyagi(geety) 
> wrote:
>>
>> Thanks for all that information Nick, it helped me a lot.
>>
>> Yes, it will be a platform specific information but may be we can just 
>> mention it in the documentation, giving the users a hint.
>>
>> -Anjul
>>
>

-- 
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/a832697d-974d-4d3d-ae27-f545a12077e1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to disable system check framework?

[Malcolm Box]

At the risk of re-opening this thread, I have just run into a very similar 
situation (see https://code.djangoproject.com/ticket/25374) and find that 
having the errors printed to the console is actually helpful - as I've had 
to silence errors to get the correct code to run, seeing if there's any 
*other* errors being "accidentally" silenced is helpful.

It seems there's actually two behaviours being conflated in 
"SILENCE_SYSTEM_CHECKS":

* Ignoring the error, so that the code will run (ie downgrade errors to 
warnings)
* Not printing the message

It's useful to be able to do the two things separately - I may want to 
downgrade an error because it's not one in my codebase, but still see if 
new instances of it creep in. Or I might want to not see any of a 
particular warning printed to the console.

Could we split this to:

IGNORED_SYSTEM_CHECKS

and 

SILENCED_SYSTEM_CHECKS


Malcolm

On Thursday, 27 August 2015 14:09:06 UTC+1, Tim Graham wrote:
>
> I created a ticket and pull request for the silencing of error/critical 
> messages:
> https://code.djangoproject.com/ticket/25318#ticket
> https://github.com/django/django/pull/5197
>
> On Tuesday, August 25, 2015 at 11:03:18 AM UTC-4, Carl Meyer wrote:
>>
>> On 08/25/2015 08:57 AM, Marcin Nowak wrote: 
>> > Well, I'm not sure now, because Tim wrote that it was a design decision 
>> > and it is well documented. 
>>
>> I still think we should change that design. It is simply wrong to have a 
>> setting called `SILENCED_SYSTEM_CHECKS` that fails to actually _silence_ 
>> the check IDs listed. 
>>
>> > Also please note that silencing specific errors is not the best 
>> solution. 
>> > In the first case E116 may be untrue and may be silenced, but for other 
>> > models this error may be true and shouldn't be silenced at all. 
>> > Silencing all E116 will give us messy information about state. 
>>
>> That's why I think in this case the best solution is to actually fix the 
>> error, not silence it; Django should be able to find a find a field even 
>> if it's monkeypatched-in, as long as the monkeypatch happens in time. 
>>
>> Carl 
>>
>>

-- 
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/dc4e410c-708f-472b-bde2-49a45ad4e39d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Get current user in model signal pre_save

[Xavier Palacín Ayuso]

Thanks

El miércoles, 9 de septiembre de 2015, 17:27:25 (UTC+2), Tom Evans escribió:
>
> On Wed, Sep 9, 2015 at 4:11 PM, Xavier Palacín Ayuso 
>  wrote: 
> > I want to collects current user in model signal pre_save, to prevent 
> remove 
> > super user permission to current super users. 
>
> Hi Xavier. This mailing list is for discussing the development of 
> django itself, not for discussing how to develop in django. 
>
> For help with developing in django, please use django-users mailing 
> list (and be patient - just because no-one has answered you in 6 hours 
> does not mean you should kick it up to django-developers). 
>
> Cheers 
>
> Tom 
>

-- 
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/f514bc25-9c1b-4fdc-bbc7-bb8886148fe8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.