Re: Feedback on PR "Add warning when inspectdb find multi-columns primary keys"

[Damien]

I agree it can be too much details but it can be useful to know which part
of inspectdb failed.

Le mar. 1 déc. 2020 à 16:46, Tim Graham  a écrit :

> What value does the traceback add for you? I'd think that most users don't
> care about the inner workings of inspectdb.
>
> On Tuesday, December 1, 2020 at 10:25:54 AM UTC-5 damio wrote:
>
>> Since the warning is to stderr, it doesn't break the main usecase of
>> doing "python manage.py inspectdb > models.py"
>>
>> Django use comment to tell that there was an error when the table
>> introspection failed, but it should be a with a detailed traceback in my
>> opinion.
>>
>> But it looks like it's me who have an unpopular opinion so I will
>> implement the PR with a comment instead of a warning.
>>
>> Le mar. 1 déc. 2020 à 16:18, Tim Graham  a écrit :
>>
>>> Please try to make it easy to understand the issue without looking at
>>> tickets and pull requests. Even after I did that, I couldn't find why you
>>> believe it should be a warning and not a comment. Why is this situation
>>> different from all the other places Django uses comments to indicate where
>>> introspection may not be perfect?
>>>
>>> Wouldn't a warning break the documented usage of inspectdb because there
>>> would be non-Python text in models.py from the warning output?
>>>
>>> $ python manage.py inspectdb > models.py
>>>
>>> On Tuesday, December 1, 2020 at 9:12:53 AM UTC-5 damio wrote:
>>>
 Hi,

 I got some feedback on the ticket that I should use comments to display
 the warning instead of stderr, since I don't really agree with that, I'm
 requesting more feedback to know which way I should do it.

 Ticket: https://code.djangoproject.com/ticket/32234
 PR: https://github.com/django/django/pull/13736

 Thanks,
 Damien

>>> --
>>> 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/NhhpjqeQ8MQ/unsubscribe
>>> .
>>> To unsubscribe from this group and all its topics, send an email to
>>> django-develop...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/b455bb92-6b91-4f2f-bdaa-8932d3cb2893n%40googlegroups.com
>>> 
>>> .
>>>
>> --
> 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/NhhpjqeQ8MQ/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/f8ce3796-dc64-470d-8ff5-ec0f400c11b4n%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAAQ5yijV_AvcKPN8av_92%2B-vFUR1gCXRPwobvHN5ozNEM5rWNA%40mail.gmail.com.

Re: Feedback on PR "Add warning when inspectdb find multi-columns primary keys"

[Tim Graham]

What value does the traceback add for you? I'd think that most users don't 
care about the inner workings of inspectdb.

On Tuesday, December 1, 2020 at 10:25:54 AM UTC-5 damio wrote:

> Since the warning is to stderr, it doesn't break the main usecase of doing 
> "python manage.py inspectdb > models.py"
>
> Django use comment to tell that there was an error when the table 
> introspection failed, but it should be a with a detailed traceback in my 
> opinion.
>
> But it looks like it's me who have an unpopular opinion so I will 
> implement the PR with a comment instead of a warning.
>
> Le mar. 1 déc. 2020 à 16:18, Tim Graham  a écrit :
>
>> Please try to make it easy to understand the issue without looking at 
>> tickets and pull requests. Even after I did that, I couldn't find why you 
>> believe it should be a warning and not a comment. Why is this situation 
>> different from all the other places Django uses comments to indicate where 
>> introspection may not be perfect?
>>
>> Wouldn't a warning break the documented usage of inspectdb because there 
>> would be non-Python text in models.py from the warning output? 
>>
>> $ python manage.py inspectdb > models.py
>>
>> On Tuesday, December 1, 2020 at 9:12:53 AM UTC-5 damio wrote:
>>
>>> Hi,
>>>
>>> I got some feedback on the ticket that I should use comments to display 
>>> the warning instead of stderr, since I don't really agree with that, I'm 
>>> requesting more feedback to know which way I should do it.
>>>
>>> Ticket: https://code.djangoproject.com/ticket/32234
>>> PR: https://github.com/django/django/pull/13736
>>>
>>> Thanks,
>>> Damien
>>>
>> -- 
>> 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/NhhpjqeQ8MQ/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to 
>> django-develop...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/b455bb92-6b91-4f2f-bdaa-8932d3cb2893n%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f8ce3796-dc64-470d-8ff5-ec0f400c11b4n%40googlegroups.com.

Re: Feedback on PR "Add warning when inspectdb find multi-columns primary keys"

[Damien]

Since the warning is to stderr, it doesn't break the main usecase of
doing "python
manage.py inspectdb > models.py"

Django use comment to tell that there was an error when the table
introspection failed, but it should be a with a detailed traceback in my
opinion.

But it looks like it's me who have an unpopular opinion so I will implement
the PR with a comment instead of a warning.

Le mar. 1 déc. 2020 à 16:18, Tim Graham  a écrit :

> Please try to make it easy to understand the issue without looking at
> tickets and pull requests. Even after I did that, I couldn't find why you
> believe it should be a warning and not a comment. Why is this situation
> different from all the other places Django uses comments to indicate where
> introspection may not be perfect?
>
> Wouldn't a warning break the documented usage of inspectdb because there
> would be non-Python text in models.py from the warning output?
>
> $ python manage.py inspectdb > models.py
>
> On Tuesday, December 1, 2020 at 9:12:53 AM UTC-5 damio wrote:
>
>> Hi,
>>
>> I got some feedback on the ticket that I should use comments to display
>> the warning instead of stderr, since I don't really agree with that, I'm
>> requesting more feedback to know which way I should do it.
>>
>> Ticket: https://code.djangoproject.com/ticket/32234
>> PR: https://github.com/django/django/pull/13736
>>
>> Thanks,
>> Damien
>>
> --
> 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/NhhpjqeQ8MQ/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/b455bb92-6b91-4f2f-bdaa-8932d3cb2893n%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAAQ5yigGWu8%3D5L5_EXS3kc99584YtiYfb2SN4eRyJOkdR7h8iQ%40mail.gmail.com.

Re: Feedback on PR "Add warning when inspectdb find multi-columns primary keys"

[Tim Graham]

Please try to make it easy to understand the issue without looking at 
tickets and pull requests. Even after I did that, I couldn't find why you 
believe it should be a warning and not a comment. Why is this situation 
different from all the other places Django uses comments to indicate where 
introspection may not be perfect?

Wouldn't a warning break the documented usage of inspectdb because there 
would be non-Python text in models.py from the warning output? 

$ python manage.py inspectdb > models.py

On Tuesday, December 1, 2020 at 9:12:53 AM UTC-5 damio wrote:

> Hi,
>
> I got some feedback on the ticket that I should use comments to display 
> the warning instead of stderr, since I don't really agree with that, I'm 
> requesting more feedback to know which way I should do it.
>
> Ticket: https://code.djangoproject.com/ticket/32234
> PR: https://github.com/django/django/pull/13736
>
> Thanks,
> Damien
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b455bb92-6b91-4f2f-bdaa-8932d3cb2893n%40googlegroups.com.

Feedback on PR "Add warning when inspectdb find multi-columns primary keys"

[damio]

Hi,

I got some feedback on the ticket that I should use comments to display the 
warning instead of stderr, since I don't really agree with that, I'm 
requesting more feedback to know which way I should do it.

Ticket: https://code.djangoproject.com/ticket/32234
PR: https://github.com/django/django/pull/13736

Thanks,
Damien

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/556c7572-1492-4211-a6e0-fa327d1fdb41n%40googlegroups.com.

Re: Fellow Reports -- November 2020

[Carlton Gibson]

Hi all. 


Calendar Week 47 -- ending 22 November.


Triaged:

https://code.djangoproject.com/ticket/32209 -- Prepend project name to 
default admin url (needsinfo)
https://code.djangoproject.com/ticket/31700 -- Highlight destructive 
operations in makemigrations output (Accepted)
https://code.djangoproject.com/ticket/32206 -- Incorrect migration 
generated if field has been renamed when it has verbose_name set (Duplicate 
of #31700)
https://code.djangoproject.com/ticket/32205 -- ORM migrations after squash, 
command sqlmigrate will be error (worksforme)
https://code.djangoproject.com/ticket/32204 -- Quick Filter for the Admin 
Sidebar (needsinfo)
https://code.djangoproject.com/ticket/27541 -- Provide hooks to override 
manifest file storage in ManifestFilesMixin (Duplicate of #27590)
https://code.djangoproject.com/ticket/32195 -- Improve error messages from 
forgetting to call .as_view() on a CBV (Accepted)
https://code.djangoproject.com/ticket/32193 -- Deprecate MemcachedCache. 
(Accepted)



Reviewed:

https://github.com/django/django/pull/13651 -- Fixed #32172 -- Adapted 
signals to allow async handlers.
https://github.com/django/django/pull/13695 -- Fixed #32206 -- Fixed 
incorrect migration generated if field has been renamed when it has 
verbose_name set.
https://github.com/django/django/pull/12187 -- Fixed #27590 -- Added 
STATICFILES_MANIFEST setting
https://github.com/django/django/pull/13686 -- Fixed #32199 -- Doc'd 
JSONField in ModelForm field mapping.
https://github.com/django/django/pull/13682 -- Fixed #32195: Improve error 
from forgetting to call .as_view() on a CBV



Authored:

https://github.com/django/django/pull/13693 -- Fixed #32202 -- Fixed 
autoreloader argument generation on Windows with Python 3.7-.





Calendar Week 48 -- ending 29 November.


Triaged:

https://code.djangoproject.com/ticket/32227 -- DebugSQLTextTestResult 
crashes when database error is raised in setUpTestData(). (Accepted)
https://code.djangoproject.com/ticket/32226 -- 
QuerySet.explain(format='json') outputs repr'd JSON on 
PostgreSQL (Accepted)
https://code.djangoproject.com/ticket/32217 -- Add warning about missing 
'migrations' package to migration docs (wontfix)
https://code.djangoproject.com/ticket/32212 -- Vary header changed by 
SessionMiddleware (wontfix)



Reviewed:

https://github.com/django/django/pull/13730 -- Refs #31978 -- Fixed hint in 
admin's password reset confirmation form for custom username fields.
https://github.com/django/django/pull/13435 -- Fixed #32018 -- Extracted 
admin colors into CSS variables.
https://github.com/django/django/pull/13525 -- Contributing Guide Overview 
Refactored
https://github.com/django/django/pull/13691 -- Fixed #32203 -- Fixed 
QuerySet.values()/values_list() crash on KeyTransforms with non-string 
values on SQLite.
https://github.com/django/django/pull/13362 -- Fixed #21936 -- Refactored 
DeleteView to work with SuccessMessageMixin.
https://github.com/django/django/pull/13714 -- Fixed #32224 -- Avoided 
suppressing connection errors in supports_json_field on SQLite.
https://github.com/django/django/pull/13697 -- Simplified JSONField key 
transforms by using JSON_OBJECT() on Oracle.
https://github.com/django/django/pull/13651 -- Fixed #32172 -- Adapted 
signals to allow async handlers.
https://github.com/django/django/pull/13711 -- Linked to FileResponse in 
Content-Disposition docs
https://github.com/django/django/pull/13305 -- Fixed #31885 -- Updated SMTP 
Email Backend to use an SSLContext.
https://github.com/django/django/pull/13134 -- Fixed #31747 -- Fixed model 
enumeration via admin URLs.
https://github.com/django/django/pull/12187 -- Fixed #27590 -- Added 
STATICFILES_MANIFEST setting
https://github.com/django/django/pull/13713 -- Fixed #32223 -- Removed 
strict=True in Path.resolve() in autoreloader.


Kind Regards, 
Carlton 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/32637edd-9628-4650-9d6b-9b7eec5d4588n%40googlegroups.com.