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

= models.PositiveBigIntegerField(primary_key=True)`` In the other hand, we could also add ``PositiveBigAutoField`` to make things easier now that we have the ability to define the ``default_auto_field`` per app. Thoughts? — Caio On 12 Apr 2020 15:01 -0300, Jure Erznožnik , wrote: > I would l

Good example of settings_changed signal usage

example that highlights a good and proper use case. I’m having a hard time trying to figure out a small and concise example. Ideas? :) — Caio -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubs

Re: Defaulting to use BigAutoField in models

What about third party apps? It would be great to migrate every AutoField to BigAutoField without the need to specify them manually. -- Caio > On 18 Jun 2020, at 09:40, Adam Johnson wrote: > > Would we be able to provide instructions on how to migrate from SIGNED INT to >

Re: Defaulting to use BigAutoField in models

exponential curve, even quite shallow, it's quite close in terms of time.) > I think this is indeed a good to have. Would we be able to provide instructions on how to migrate from SIGNED INT to UNSIGNED BIG INT? Perhaps a management command that outputs SQL like sqlmigrate? -- Cai

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: Remove automatic date-naming of migrations (00XX_auto_YYYMMDD)

are fixed to “auto”. We use a similar technique to those mentioned in the blog post to do that. The reason is that we want to force developers to get conflicts (git) on migration names during the review process, rather than having to handle migration merging manually during deploy -- Caio >

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

behavior. -- Caio > On Apr 10, 2020, at 04:29, Nick Pope wrote: > > People can also choose to set this for a third-party app by subclassing the > AppConfig, but as you say, they'd then be forced to handle migrations > manually - is this even avoidable? I'm not sure how

Adding ability to choose AutoField type (signed vs unsigned)

T_AUTOFIELD to PositiveBigAutoField for new projecst, as suggested in Nick Pope's comment above. Thank you -- Caio -- 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

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 Man

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: Improve migration conflict detection

esolver-hook > > On Feb 11, 2020, at 1:42 PM, Caio Ariede > > wrote: > > Hey folks, > > I was looking at the code used to detect conflicts in migrations [1]. It > seems to use a very safe approach, by avoiding with multiple node leafs in > the migration graph.

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)"