Re: Another approach to ticket373:Add support for multiple-column primary keys

[Arisophy]

Hi, Adam

Thanks for your reply.

I added limitations to GitHub.

https://github.com/Arisophy/django-compositepk-model/blob/main/README.md#limitations

For now, that's what I'm aware of.
And , I posted my blog about my implementation and opinion.

https://gijutsu.com/en/2021/03/16/django-ticket373/

regards

Arisophy


2021年3月16日(火) 4:36 'Adam Johnson' via Django developers (Contributions to
Django itself) :

> Hi Arisophy
>
> I am interested in seeing composite PK's land in Django - I recently made
> a composite PK table for a client with a hack to make it work on Django.
> I'm sure others are interested too - I just guess at this point there is
> not so much momentum on the topic since it's so long running with no
> solution.
>
> Your approach seems to be fairly limited, so perhaps it's gotten easier
> with recent ORM improvements. How well does your method work? Are there any
> limitations with which queries are supported, migrations, etc.?
>
> Thanks,
>
> Adam
>
> On Fri, 29 Jan 2021 at 14:31, Arisophy  wrote:
>
>> Hi, django developers.
>>
>> Is anyone still interested in ticket373?
>>
>> https://code.djangoproject.com/ticket/373
>>
>> I'm gradually migrating legacy systems built with Ruby On Rails to
>> Django. So made an extended Model class that supports composite primary
>> keys.
>>
>> https://github.com/Arisophy/django-compositepk-model
>>
>> It worked nicely with a small amount of code.
>>
>> FYI
>>
>> Arisophy
>>
>> --
>> 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/CA%2B2LtkDBof5M9aG-QjgeUTa9EbXRCtnNEOCqqt2aT%3DeexN4DGA%40mail.gmail.com
>> 
>> .
>>
>
>
> --
> Adam
>
> --
> 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/CAMyDDM2VAnD6tLwdO2oFLaqpxmUJ%3Dg_GJAa3RdstV0H3Lntrsg%40mail.gmail.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/CA%2B2LtkCDZ%3DrEdprYQg34D9S5DuO-X68yi08QCJAFRV98SYygNQ%40mail.gmail.com.

Re: request to reopen ticket #24522: --random test option

['Adam Johnson' via Django developers (Contributions to Django itself)]

>
> because I think the number of tests inside a PR is small enough that you
> probably do not see isolation failures, but you really want to see progress
> in a PR without random failures due to isolation.
>

I think it's the opposite - most isolation problems are best detected at
the time they're introduced. So using a different seed for each run of a PR
as it's updated will help flush out any newly authored isolation problems
before merging.

It's highly more likely that running tests in reverse order will catch
> isolation issue for you than running them in a non-deterministic order.
>

There's actually a study on this, across Apache projects - see the link in
https://github.com/adamchainz/pytest-reverse#history . They found that
random is best, with reverse being almost as good.

Reverse order fails to find three-way-plus isolation failures, e.g. in
tests A, B, C where B depends on a side-effect triggered in both A and C.
Both the ABC and CBA orders allow the side effect to leak into test B so
the failure is not detected.

We have to run it as often with as many different seeds as possible to have
> an effect. The space of tests is so big that I am not sure we'd find
> something otherwise (though I have to agree that is theoretical thinking I
> did not try in practice).
>

Only two randomly sorted test runs are needed to flush out most pairwise
problems. For example, imagine test B depends on a side effect of test A.
Each random test run has a 50% order of running A then B, or B then A. So
the expected number of test runs to see the isolation failure is 2. Yes,
one could see 32 test runs in a row without the failure, but the chance of
that is 1 in 2^32.

For three-way isolation problems, you might expect more runs, depending on
how many of the 6 possible configurations of 3 tests reveal the problem.
For four-way it could be worse again. But at least such isolation problems
will appear eventually, as opposed to never.

On Fri, 12 Mar 2021 at 17:02, Florian Apolloner 
wrote:

> Thank you for diving into how unittest discovery tests!
>
> On Friday, March 12, 2021 at 12:14:05 PM UTC+1 chris.j...@gmail.com wrote:
>
>> But, regardless of the default, to get the full benefit I think you'd
>> want at least one of the test runs in CI to be a random one.
>>
>
> This is were I somewhat disagree. We have to run it as often with as many
> different seeds as possible to have an effect. The space of tests is so big
> that I am not sure we'd find something otherwise (though I have to agree
> that is theoretical thinking I did not try in practice).
>
> Cheers,
> Florian
>
> --
> 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/4034f3db-e6ee-4d78-b140-553c73c1a170n%40googlegroups.com
> 
> .
>


-- 
Adam

-- 
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/CAMyDDM1fk1AGcE%3Dm9zq3UrOdZ%3D2EPsstSgDOjmOzyCekdSp%2BbA%40mail.gmail.com.

Query regarding Google Summer Of Code

[Muskan Vaswan]

Hello again, I am Muskan and I have a few questions regarding GSoC 2021.

Are contributions to django/djangoproject (the tickets trac) considered in 
GSoC. While the dashboard itself is mentioned on the wiki page I was 
wondering if it extends to the issue tracker itself to. If so, then would 
fixing UI/UX bugs (large enough) be considered a valid contribution to 
GSoC? 
Besides this, regardless of GSoc, what is the process of approval for UI/UX 
fixes in any of the django projects/sub-projects? Does this process stay 
the same in consideration of a GSoC proposal?

Is there any mentor or such, that we as GSoC aspirants can get in tough 
with before the submissions of proposals so we can more more freely ask 
doubts specifically related to our potential proposals?

-
Regards
Muskan Vaswan

-- 
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/f1bf29ea-f7ce-421d-8c3d-b3af9c6d89c8n%40googlegroups.com.

Re: Fail test runs on unraisable exceptions?

['Adam Johnson' via Django developers (Contributions to Django itself)]

>
> Would we need to run “gc.collect” after each test to make it deterministic?
>

Not particularly. In CPython, most objects are deterministically deleted
when they go out of scope. Only circular references are gathered by the
garbage collector, and I think it's okay to leave them as-is - the
exception should be clear enough to debug such rare occurences.

I finally created a ticket for this, linking to the pytest reference
implementation: https://code.djangoproject.com/ticket/32557

I also created a ticket for a similar feature, tracking exceptions in
threads that aren't picked up by the main thread:
https://code.djangoproject.com/ticket/32558

On Sat, 31 Oct 2020 at 08:22, Carlton Gibson 
wrote:

>
>
> On 30 Oct 2020, at 17:29, Adam Johnson  wrote:
>
> Focussing only on the asyncio case may be counter productive. They are
> warnings by default and it requires a warning filter to convert them to
> exceptions, which are then unraisable.
>
>
> OK, makes sense. Thanks for explaining it. Given that, seems worth a try
> yes. +1
>
> --
> 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/351D56E9-B52D-4F3A-9CCE-072C206FEA96%40gmail.com
> 
> .
>


-- 
Adam

-- 
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/CAMyDDM3_-7bhW6e7e0utM1Pi95RXdfkAE01zFghv-D4f%3DtBwrA%40mail.gmail.com.

Proposal to add attribute 'step' to FloatField and DecimalField

[Jacob Rief]

If someone wants to use the step attribute as provided by the HTML field
 , she/he has to specify that using for instance
FloatField(widget=NumberInput(attrs={'step': 0.5})).

Since the HTML standard offers a step attribute on input fields of type 
number,
from my point of view, this feature shall be reflected by Django's 
FloatField and 
optionally DecimalField rather than having to parametrize the widget.

Min- and max-values are already supported by the FloatField, so the 
step-value
would make sense here as well. It furthermore would require to revalidate 
the
step-value by Django's Form validation, rather than by HTML alone.

– Jacob

-- 
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/9a35aa63-0d22-4353-8f58-70a181e05791n%40googlegroups.com.

Re: Proposal to add attribute 'step' to FloatField and DecimalField

[Markus Holtermann]

Hi Jacob,

That sounds like a sensible feature. Do you want to open a ticket and maybe 
implement it?

Cheers

Markus

On Wed, Mar 17, 2021, at 12:45 AM, Jacob Rief wrote:
> If someone wants to use the step attribute as provided by the HTML field
>  , she/he has to specify that using for instance
> FloatField(widget=NumberInput(attrs={'step': 0.5})).
> 
> Since the HTML standard offers a step attribute on input fields of type 
> number,
> from my point of view, this feature shall be reflected by Django's 
> FloatField and 
> optionally DecimalField rather than having to parametrize the widget.
> 
> Min- and max-values are already supported by the FloatField, so the step-value
> would make sense here as well. It furthermore would require to revalidate the
> step-value by Django's Form validation, rather than by HTML alone.
> 
> – Jacob
> 
> -- 
> 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/9a35aa63-0d22-4353-8f58-70a181e05791n%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/35ea5249-6c7d-44c6-8171-0730e0a660bd%40beta.fastmail.com.

Re: Query regarding Google Summer Of Code

[Ahmad A. Hussein]

Hello Muskan,

"We're still going to be strict with what we accept - you'll need to
provide a *strong use case* for your idea and show that it would be *useful
to a majority of developers* or *significantly improve* the development of
Django itself."

This is from the wiki page
 for GSoC 2021. So I
believe you could submit a GSoC proposal for UI/UX but your proposal would
need to greatly impact a sizable amount of developers.

As for UI/UX fixes, I believe the process is the same as normal tickets:
you submit a ticket on the issue tracker, people review it and establish
consensus, and then you submit a patch following said consensus.

If you're looking to get feedback on your proposal, submit it on the forums
 under Mentorship. Plenty of people will
take a look at it and will help you get on the right track.

On Tue, Mar 16, 2021 at 7:50 PM Muskan Vaswan 
wrote:

> Hello again, I am Muskan and I have a few questions regarding GSoC 2021.
>
> Are contributions to django/djangoproject (the tickets trac) considered in
> GSoC. While the dashboard itself is mentioned on the wiki page I was
> wondering if it extends to the issue tracker itself to. If so, then would
> fixing UI/UX bugs (large enough) be considered a valid contribution to
> GSoC?
> Besides this, regardless of GSoc, what is the process of approval for
> UI/UX fixes in any of the django projects/sub-projects? Does this process
> stay the same in consideration of a GSoC proposal?
>
> Is there any mentor or such, that we as GSoC aspirants can get in tough
> with before the submissions of proposals so we can more more freely ask
> doubts specifically related to our potential proposals?
>
> -
> Regards
> Muskan Vaswan
>
> --
> 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/f1bf29ea-f7ce-421d-8c3d-b3af9c6d89c8n%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/CAJNa-uMgEkStpU_z%3DgwFBuR7i43Hao5pnHQZBs-o-fth0nbE9w%40mail.gmail.com.