Re: Hi i'm new on python and django!

[Carlton Gibson]

Hi Juan.

The #123 will refer to a ticket number on the Django Trac issue tracker
instance.
So that would be:

https://code.djangoproject.com/ticket/123 (which was a while back…)

Have a browse around there and get comfortable.

Filtering by component is a useful way to break it down.
Here’s a filter for all the open tickets on the Django Admin:

https://code.djangoproject.com/query?status=assigned&status=new&component=contrib.admin&col=id&col=summary&col=status&col=owner&col=type&col=component&col=version&desc=1&order=id

The Triaging Tickets section of the Contributing Guide gives a good outline
of the workflow:

https://docs.djangoproject.com/en/3.2/internals/contributing/triaging-tickets/

Hopefully this helps to get you started.
Welcome aboard ⛵️

Kind regards,
Carlton


On Wed, 12 May 2021 at 00:58, Juan Leon 
wrote:

> anyone can help me to understandt how i can start in django, with any
> tips... because in the moment when i clone the project in local i saw
> commits with "hastags", for example: #123 what is the significate of this
> and how can i work with that?
>
> i am going to really appreciate yours answers 😃
>
> --
> 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/a53086e4-86f6-4371-9fc5-048fad19df61n%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/CAJwKpyTXSR57dprCfwpfBUOpTVBV30vGsLxMShA13nvVvrJWqQ%40mail.gmail.com.

Re: Update returning

[Tom Carrick]

Apologies, I had totally forgotten about this, but I'm still interested in
working on it, but still not sure about a few things.

I've been thinking about the return value a bit. I can foresee cases where
you wouldn't want the id returned.  You might want the user to update
something by slug, username, or some other identifier without revealing the
IDs. Of course the user could reformat the return value however they like,
but I don't see a reason to ask for something that isn't necessary.

So I think a list of some kind of object (namedtuple or dict probably)
makes the most sense to me. As for also adding the count, I am not sure.
The return value would then be e.g. (1, []). I'm guessing this count
would remain as the number of matched rows, rather than the updated ones -
I am not sure if returning only gives back rows that were modified or not,
the Postgres docs are at least unclear on this. If they're always going to
be the same, I'm not sure there is much reason for returning the count when
len(return_value) will do.

I'm also not really sure on the data structure though. Namedtuples make the
most sense to me but a dict might be useful for those wanting to shove this
directly into JsonResponse, without needing _asdict(), for example.

Cheers,
Tom

On Wed, 27 Jan 2021 at 10:45, Florian Apolloner 
wrote:

> Hi Simon,
>
> On Wednesday, January 27, 2021 at 5:54:42 AM UTC+1 charettes wrote:
>
>> I think that's the best option here if we want to elegantly add support
>> for this feature while maintaining backward compability. Something along
>> the lines of ...
>>
>
> That is certainly an interesting approach. It kinda breaks the "there
> should be one way of doing things" rule, but…
>
> The usage of `returning` bring another set of questions though. Since
>> UPDATE are not ordered RETURNING data has little value without the primary
>> key associated with the updated rows. Maybe the return value of
>> `returning=[f1, ..., fn]` should be a dict mapping the primary key to list
>> of returning values.
>>
>
> I am not sure I like that. For things where you update just one row and
> want to know the new values the primary key doesn't make much sense.
> Granted for multiple rows it would maybe easier to have it automatically
> keyed by the pk, but returning something always (the pk) without having an
> option to disable  it seems kinda wrong to me. Not sure what the best
> option would be.
>
> 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/4eea605a-57d7-4ce3-b233-3eb88c91e110n%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/CAHoz%3DMa2DVUXHotoHW_XB91eW6imgV_Evc%2B4-ApFqwACEa0jnA%40mail.gmail.com.

Re: Do people actually squash migrations?

['Mike Lissner' via Django developers (Contributions to Django itself)]

So sort of sounds like an update to the squash migration docs is needed if 
this is representative of the general sentiment. Looking at the section on 
this 
,
 
the general outline is:

1. Overview
2. How it works
3. The commands
4. Gotchas
5. A bunch of wonky stuff you have to do ("Update all migrations that 
depend on the deleted migrations", "Remove the 'replaces' attribute in the 
Migration class ")
6. Another gotcha in an info box

Would it be a bad idea to update the docs to bifurcate this section so it 
has an intro that says something like:

As you work on your project you will create more and more migrations. When 
> they get to be too many, there are two approaches to trimming them down. 
> The first is to use the squashmigrations command and process to create a 
> merged migration file, however this approach comes with a number of caveats 
> and gotchas that often make it impractical. The second way is to coordinate 
> with your team to ensure that all installations of your app are up to date, 
> then to have a coordinated day when migrations are removed and recreated 
> from scratch. Which one is best for your organization will depend on the 
> complexity of your project and the flexibility of your team.
>

>From there, the docs could go on to explain first how to do this manually, 
then move onto the squashmigrations docs. This disfavors squashmigrations 
by putting it after the manual approach, but after this conversation (and 
my experience) that seems right to me. 

I haven't done the manual approach but I imagine it's something like:

1. Check your migrations across all apps with interdependencies for 
RunPython or RunSQL code.
2. If found, make a decision about keeping or deleting that code.
3. Delete all migrations across all apps that have interdependencies.
4. Run the makemigrations command
5. Add your custom RunPython or RunSQL code back

That'd be a big demotion for the squashmigrations code. I don't know how 
married we are to it, but it seems like there's not much energy for making 
it better and that lots of people have already demoted it in their minds 
and workflows.

Thanks, 


Mike


 

-- 
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/80b1040d-3e62-4cf9-b2f8-991c5de221c7n%40googlegroups.com.

Re: Do people actually squash migrations?

['Mike Lissner' via Django developers (Contributions to Django itself)]

Oh, I guess there's also a step in the manual process to reset the 
migrations table in the DB, but I don't know how to do that. Tricky stuff! 

On Wednesday, May 12, 2021 at 9:37:53 AM UTC-7 Mike Lissner wrote:

> So sort of sounds like an update to the squash migration docs is needed if 
> this is representative of the general sentiment. Looking at the section 
> on this 
> ,
>  
> the general outline is:
>
> 1. Overview
> 2. How it works
> 3. The commands
> 4. Gotchas
> 5. A bunch of wonky stuff you have to do ("Update all migrations that 
> depend on the deleted migrations", "Remove the 'replaces' attribute in 
> the Migration class ")
> 6. Another gotcha in an info box
>
> Would it be a bad idea to update the docs to bifurcate this section so it 
> has an intro that says something like:
>
> As you work on your project you will create more and more migrations. When 
>> they get to be too many, there are two approaches to trimming them down. 
>> The first is to use the squashmigrations command and process to create a 
>> merged migration file, however this approach comes with a number of caveats 
>> and gotchas that often make it impractical. The second way is to coordinate 
>> with your team to ensure that all installations of your app are up to date, 
>> then to have a coordinated day when migrations are removed and recreated 
>> from scratch. Which one is best for your organization will depend on the 
>> complexity of your project and the flexibility of your team.
>>
>
> From there, the docs could go on to explain first how to do this manually, 
> then move onto the squashmigrations docs. This disfavors squashmigrations 
> by putting it after the manual approach, but after this conversation (and 
> my experience) that seems right to me. 
>
> I haven't done the manual approach but I imagine it's something like:
>
> 1. Check your migrations across all apps with interdependencies for 
> RunPython or RunSQL code.
> 2. If found, make a decision about keeping or deleting that code.
> 3. Delete all migrations across all apps that have interdependencies.
> 4. Run the makemigrations command
> 5. Add your custom RunPython or RunSQL code back
>
> That'd be a big demotion for the squashmigrations code. I don't know how 
> married we are to it, but it seems like there's not much energy for making 
> it better and that lots of people have already demoted it in their minds 
> and workflows.
>
> Thanks, 
>
>
> Mike
>
>
>  
>

-- 
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/ce1cb4d6-905f-4411-93df-4449796558a8n%40googlegroups.com.

Re: Do people actually squash migrations?

[Ryan Hiebert]

You’d run the migrations that you manually created with --fake. My experience 
also corroborates the idea that squashmigrations may be unsuitable for many 
situation that are similar to mine, where I am able to fully control the full 
set of places that the code is deployed.

Ryan

> On May 12, 2021, at 11:40 AM, 'Mike Lissner' via Django developers 
> (Contributions to Django itself)  wrote:
> 
> Oh, I guess there's also a step in the manual process to reset the migrations 
> table in the DB, but I don't know how to do that. Tricky stuff! 
> 
> On Wednesday, May 12, 2021 at 9:37:53 AM UTC-7 Mike Lissner wrote:
> So sort of sounds like an update to the squash migration docs is needed if 
> this is representative of the general sentiment. Looking at the section on 
> this 
> ,
>  the general outline is:
> 
> 1. Overview
> 2. How it works
> 3. The commands
> 4. Gotchas
> 5. A bunch of wonky stuff you have to do ("Update all migrations that depend 
> on the deleted migrations", "Remove the 'replaces' attribute in the Migration 
> class ")
> 6. Another gotcha in an info box
> 
> Would it be a bad idea to update the docs to bifurcate this section so it has 
> an intro that says something like:
> 
> As you work on your project you will create more and more migrations. When 
> they get to be too many, there are two approaches to trimming them down. The 
> first is to use the squashmigrations command and process to create a merged 
> migration file, however this approach comes with a number of caveats and 
> gotchas that often make it impractical. The second way is to coordinate with 
> your team to ensure that all installations of your app are up to date, then 
> to have a coordinated day when migrations are removed and recreated from 
> scratch. Which one is best for your organization will depend on the 
> complexity of your project and the flexibility of your team.
> 
> From there, the docs could go on to explain first how to do this manually, 
> then move onto the squashmigrations docs. This disfavors squashmigrations by 
> putting it after the manual approach, but after this conversation (and my 
> experience) that seems right to me. 
> 
> I haven't done the manual approach but I imagine it's something like:
> 
> 1. Check your migrations across all apps with interdependencies for RunPython 
> or RunSQL code.
> 2. If found, make a decision about keeping or deleting that code.
> 3. Delete all migrations across all apps that have interdependencies.
> 4. Run the makemigrations command
> 5. Add your custom RunPython or RunSQL code back
> 
> That'd be a big demotion for the squashmigrations code. I don't know how 
> married we are to it, but it seems like there's not much energy for making it 
> better and that lots of people have already demoted it in their minds and 
> workflows.
> 
> Thanks, 
> 
> 
> Mike
> 
> 
>  
> 
> -- 
> 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/ce1cb4d6-905f-4411-93df-4449796558a8n%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/274F3484-1784-4C0C-8ADC-552E1870C61C%40ryanhiebert.com.

Re: Do people actually squash migrations?

[Raffaele Salmaso]

On Wed, May 12, 2021 at 2:50 AM 'Mike Lissner' via Django developers
(Contributions to Django itself)  wrote:

> So, my question is: Do people actually use squashmigrations with success?

For what is worth: yes. The only problem I have is a pbcak problem (I like
to do esoteric things just because).

-- 
| Raffaele Salmaso
| https://salmaso.org
| https://bitbucket.org/rsalmaso
| https://github.com/rsalmaso

-- 
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/CABgH4Jts6Xaxa5B9Awha3Ey%3DC8c1KMowtDPA%2BrPREZCbGRnEJA%40mail.gmail.com.

Fellow Reports - May 2021

[Mariusz Felisiak]

Week ending May 9, 2021


Released Django 3.2.2, 3.1.10, and 2.2.22.

*Triaged:*
    https://code.djangoproject.com/ticket/32704 - QuerySet.defer() 
doesn't clear deferred field when chaining with only(). (accepted)
    https://code.djangoproject.com/ticket/32706 - Ambiguity around 
field choices in the Model Field section (invalid)
    https://code.djangoproject.com/ticket/32708 - Django cron file lock 
breaks with django 3.2 (invalid)
    https://code.djangoproject.com/ticket/32701 - Oracle AWD/ATP Wallet 
Use additional configurations needed for Mac environment (wontfix)
    https://code.djangoproject.com/ticket/32709 - Examples in 
django.utils.baseconv.BaseConverter's docstring are incorrect. (accepted)
    https://code.djangoproject.com/ticket/32712 - Depracate the 
django.utils.baseconv module. (created)
    https://code.djangoproject.com/ticket/32710 - static template tag 
converts '?' to '%3F' (wontfix)
    https://code.djangoproject.com/ticket/32713 - URLValidator tests 
failing on Python versions patched for bpo-43882 (accepted)
    https://code.djangoproject.com/ticket/32715 - Duplicated CRUD 
permissions when renaming a model (duplicate)
    https://code.djangoproject.com/ticket/32716 - 
ManifestStaticFilesStorage crashes with max_post_process_passes = 0. 
(accepted)
    https://code.djangoproject.com/ticket/32717 - Incorrect SQL 
generation filtering OR-combined queries (accepted)
    https://code.djangoproject.com/ticket/32720 - Add configuration for 
Sphinx linkcheck builder. (accepted)
    https://code.djangoproject.com/ticket/32722 - Comparing to 
TruncTime() doesn't work on Oracle. (created)
    https://code.djangoproject.com/ticket/32729 - formulario de 
registro se muestra debajo de todas las apps en administrador django 
(duplicate)


*Reviewed/committed:*
    https://github.com/django/django/pull/14344 - Fixed #32709 -- 
Corrected examples in django/utils/baseconv.py docstring.
    https://github.com/django/django/pull/14336 - Fixed #32693 -- 
Quoted and lowercased generated column aliases.
    https://github.com/django/django/pull/14253 - Refs #32074 -- 
Removed usage of deprecated Thread.setDaemon().
    https://github.com/django/django/pull/14350 - Fixed #32714 -- 
Prevented recreation of migration for Meta.ordering with OrderBy 
expressions.
    https://github.com/django/django/pull/14334 - Fixed #32479 -- Added 
fallbacks to subsequent language codes in translations.
    https://github.com/django/django/pull/14341 - Fixed #32690 -- Fixed 
__in lookup crash when combining with filtered aggregates.
    https://github.com/django/django/pull/14353 - Refs CVE-2021-31542 
-- Skipped mock AWS storage test on Windows.
    https://github.com/django/django/pull/14337 - Fixed #32699 -- Fixed 
comparing to TruncTime() with 0 microseconds on MySQL.
    https://github.com/django/django/pull/14356 - Fixed #32712 -- 
Deprecated django.utils.baseconv module.
    https://github.com/django/django/pull/14268 - Fixed #32670 -- 
Allowed GDALRasters to use any GDAL virtual filesystem.


*Authored:*
    https://github.com/django/django/pull/14345 - Refs #32074 -- Used 
asyncio.get_running_loop() instead of get_event_loop().
    https://github.com/django/django/pull/14349 - Fixed #32713, Fixed 
CVE-2021-32052 -- Prevented newlines and tabs from being accepted in 
URLValidator on Python 3.9.5+.
    https://github.com/django/django/pull/14365 - Fixed #32722 -- Fixed 
comparing to TruncTime() on Oracle.


Best,
Mariusz

--
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/8be90515-1c67-5e76-e101-3709a1b99b2d%40gmail.com.