Improve migration conflict detection

://github.com/django/django/blob/e3f6e18513224c8ad081e5a19da641f49b0b43da/django/db/migrations/loader.py#L301-L313 -- Caio Ariede caio.ari...@gmail.com -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)"

Re: Improve migration conflict detection

ions/loader.py#L301-L313 -- Caio Ariede caio.ari...@gmail.com > On Feb 13, 2020, at 11:49, Dave Vernon wrote: > > If I had to guess, it would be that with more than one leaf node, you would > end up a substantial challenge resolving dependancies which would create an > Ord

Re: [GSoC 2020] Secrets Manager Proposal

I’m not sure if you did this already, but I would also look at how existing third-party libraries are handling this. -- Caio > On Mar 21, 2020, at 02:01, Abhirav Dilip Kariya wrote: > > Hello everyone, > > I’ve submitted my proposal draft for GSoC for the 'Secrets Manager' idea > listed

Adding ability to choose AutoField type (signed vs unsigned)

Hi folks, I’ve been working on ticket #56 "Primary key columns should be UNSIGNED" (really old) for a while now. It’s cumbersome and hard to fix for some reasons, including backwards compatibility, nothing that a single PR can solve but I’ll try to summarize where things are at this moment. Ho

Re: Adding ability to choose AutoField type (signed vs unsigned)

I believe that it is already possible to trigger new migrations in a third-party app by changing its AppConfig.label, for example. Please correct me if I’m wrong. >From that perspective, it think it wouldn’t be wrong if a migration is created >after someone changes its AppConfig’s default_auto_

Re: Remove automatic date-naming of migrations (00XX_auto_YYYMMDD)

I think making it possible to customize how migration names are generated has a great value. Changing something from “auto” to some better/descriptive name has its value, but I can also see people creating their own strategies for naming migrations. I work on a project where migration names are

Re: Defaulting to use BigAutoField in models

For the record, there was a related discussion a few months ago: https://groups.google.com/d/msg/django-developers/VFXZpHnuEJc/bbefjX9yCQAJ > On 11 Jun 2020, at 12:28, Tom Forbes wrote: > > nsures it will be used meaningfully and not forgotten about until it’s too > late. > -- You received

Re: Defaulting to use BigAutoField in models

> On 17 Jun 2020, at 16:56, Adam Johnson wrote: > > I think special casing the migrations framework is an avenue to explore, so I > created this today and to my surprise it seems to work quite well: > https://github.com/orf/django/commit/0a335f208cee1376c25eff55c6f866de122c7839 >

Re: Defaulting to use BigAutoField in models

UNSIGNED BIG INT? Perhaps a management command that outputs SQL like > sqlmigrate? > > It would only be needed to add this to the model: > id = BigAutoField() > > Then migrations would pick it up, because the field is no longer auto_created. > > On Thu, 18 Jun 2020 at

Good example of settings_changed signal usage

Hello folks, I want to add a good example of usage for the settings_changed signal to the documentation: https://docs.djangoproject.com/en/dev/ref/signals/#setting-changed I was looking around the web and it seems there is some confusion around its proper use, so I’d like to add a good example

Re: Adding ability to choose AutoField type (signed vs unsigned)

ing the discussion with my uninformed > ideas, but perhaps the minor change could be handled in a simpler > manner like proposed above. > > LP, > Jure > > On Sat, Apr 11, 2020 at 12:21 AM Caio Ariede wrote: > > > > I believe that it is already possible to trigger