Re: Making startproject's settings more 12-factor-y

[Florian Apolloner]

On Sunday, June 28, 2020 at 1:23:25 AM UTC+2 timog...@gmail.com wrote:

> It seems like it could be insecure to move that to a system check as "For 
> performance reasons, checks are not run as part of the WSGI stack that is 
> used in deployment." (Also, it seems impossible to write a system check 
> that determines whether or not a project will consult SECRET_KEY.)
>

The check if it is empty can be done on access in LazySettings without any 
real overhead. We are even calling url validators when access 
MEDIA_URL/STATIC_URL 
(https://github.com/django/django/blob/62d85a283500e9abb0e1c9ec53c59be468f056a0/django/conf/__init__.py#L152-L158)
 
-- so we really don't have to talk about overhead here :D

I will try to remove those properties and move the checks into 
`__getattr__`, this should result in a (small) one time overhead. PR(s) to 
follow.

I think a deployment system check for non-empty SECRET_KEY might also make 
sense.

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/688bcec8-ed3f-4c35-bdf2-ad5fe4929ca4n%40googlegroups.com.

Re: Making startproject's settings more 12-factor-y

[Florian Apolloner]

As promised the PR: https://github.com/django/django/pull/13120 I also had 
to touch TokenResetGenerator since it stores the secret in a class level 
variable and that would prevent the server startup either way… 

Let's see what the full test suite says, but I cannot really imagine many 
issues.

On Sunday, June 28, 2020 at 10:27:44 AM UTC+2 Florian Apolloner wrote:

> On Sunday, June 28, 2020 at 1:23:25 AM UTC+2 timog...@gmail.com wrote:
>
>> It seems like it could be insecure to move that to a system check as "For 
>> performance reasons, checks are not run as part of the WSGI stack that is 
>> used in deployment." (Also, it seems impossible to write a system check 
>> that determines whether or not a project will consult SECRET_KEY.)
>>
>
> The check if it is empty can be done on access in LazySettings without any 
> real overhead. We are even calling url validators when access 
> MEDIA_URL/STATIC_URL (
> https://github.com/django/django/blob/62d85a283500e9abb0e1c9ec53c59be468f056a0/django/conf/__init__.py#L152-L158)
>  
> -- so we really don't have to talk about overhead here :D
>
> I will try to remove those properties and move the checks into 
> `__getattr__`, this should result in a (small) one time overhead. PR(s) to 
> follow.
>
> I think a deployment system check for non-empty SECRET_KEY might also make 
> sense.
>
> 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/596f6a5b-7ca0-4dd3-b765-f4d559758920n%40googlegroups.com.

Django project to run on nodes independently for data entry and sync with server when possible

[BRAJESH KUMAR]

Hi, I am trying to develop a webpage which should be able to run based on a database (MySQL preferred) . the problem I am facing is to handle the situation at node computers where data entry is being done, if the internet is down, could it save a local copy of the database and allow to merge with the server copy once the network is available. Regards,Brajesh



-- 
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/7196EF45-4DD3-4870-8DD8-CF0999619046%40hxcore.ol.

Re: Defaulting to use BigAutoField in models

[Tom Forbes]

I spent some time last week experimenting with my patch, the biggest issue 
I could find was that under some situations we add explicit casts to array 
fields in Postgres based on the *expected* PK field type (i.e `WHERE 
[1,2,3]::int @> [1,2,3]::bigint`) which causes the query to be invalid. The 
casts all look redundant however working out when they are redundant is 
pretty complex, so I'm not sure if this approach has any legs.

> Regarding third party apps a solution could be to allow a per-app config 
option or encourage them to explicitly choose which primary key they use 
for their model but I'm not a big fan of baking logic in the migration 
framework to treat some fields in a special way.

Auto-generated M2M tables are an issue here, we would need to add some 
option to ManyToManyField() to allow passing in a PK field type. But I like 
the approach of just saying "if you ship migrations, be explicit about your 
primary keys" as it seems pretty simple.

Overall I think your two phase plan seems like a good approach 🙌 - lets do 
it?

On Thursday, 18 June 2020 at 15:18:35 UTC+1 charettes wrote:

> +1 from me as well but I don't think we should add any logic to the 
> migration framework to handle the transition.
>
> I think the release plan should be something along the following
>
> Phase 1:
> - New projects are generated with MODEL_DEFAULT_PK = 
> 'django.db.models.BigAutoField'
> - A system check or warning is emitted when the setting is not defined and 
> MODEL_DEFAULT_PK default to 'django.db.models.AutoField' during the 
> transition period. The warning should warn that the value will default to 
> 'django.db.models.AutoField' in a future version of Django.
> - An upgrade path is mentioned in the docs to mention that explicit ` id = 
> AutoField()` must be assigned to preserve previous behaviour and avoid 
> migrations. This one of the thing projects such as django-codemod could 
> really help with[0]
>
> Phase 2:
> - settings.MODEL_DEFAULT_PK now defaults to 'django.db.models.BigAutoField'
> - System check/warning about undefined MODEL_DEFAULT_PK setting is removed.
> - Let the migration framework generate migrations just like it normally 
> would for projects that didn't follow the documented migration path.
> - Optionally add a system check that warns about usage of `AutoField` 
> because of its possible overflow.
>
> > I think we should restrict the setting between normal and big auto 
> fields only. Allowing UUID's would be changing the type, with the potential 
> for havoc with code incompalities throughout django. It's also not possible 
> to migrate tables over to the new type.
>
> I'm not sure I agree here. For folks that are setting a up a new project 
> starting with UUIDField primary keys can be useful and if we're adding a 
> setting for this purpose I think we should it make it as flexible as 
> possible.
>
>
> [0] https://github.com/browniebroke/django-codemod
>
> Le jeudi 11 juin 2020 11:28:59 UTC-4, Tom Forbes a écrit :
>>
>> I’d like to re-propose switching Django to use BigAutoField’s rather than 
>> the current AutoField. This has been proposed[1] before (and a MR made[2]) 
>> but it was closed due to implementation issues and not much else has 
>> happened since then.
>>
>> As many of you are aware the max value a standard AutoField can hold is 
>> 2,147,483,647 (2.1 billion) which sounds like more than you can ever need. 
>> But it’s often not, and you only find out at the worst possible time - out 
>> of the blue at night and during a period of rapid growth. The process for 
>> fixing this issue also becomes a lot harder as your data grows - when 
>> you’ve hit the limit you’re looking at a multi-hour `ALTER TABLE` on 
>> Postgres during which writes and reads are blocked, or a risky operation to 
>> create a new table with the correct primary key and copy old data over in 
>> batches. Basically if you’ve experienced this before you wouldn’t wish it 
>> on your worst enemy.
>>
>> I’m proposing that we add a `MODELS_PRIMARY_KEY` (name improvements 
>> welcome!) setting that _defaults_ to `BigAutoField`, with prominent 
>> docs/release notes saying that to preserve the existing behaviour this 
>> should be set to `AutoField`. I think this the only realistic way we can 
>> implement this for new projects in a way that ensures it will be used 
>> meaningfully and not forgotten about until it’s too late.
>>
>> Rails managed to do this migration somewhat painlessly due the big 
>> differences between Rails and Django models. As Django migrations are 
>> derived from the current model state so there’s no way I can think of to 
>> express “make this auto-generated field a BigAutoField only if this model 
>> is *new*”. The way I see it is that a global setting is very easy to 
>> toggle and there is little chance of missing the large numbers of 
>> migrations that would be generated during the Django update. Smaller 
>> applications could apply the migrations with little issue an

Thanks for standing up against racism, xenophobia, and all other forms of inequality.

[Bigdatamonk Inc.]

Hello everyone,

I know it's not an appropriate platform to discuss non-technical things.
But I just noticed #BlackLivesMatter message on the Django website. And, I
couldn't stop myself from shooting this mail to everyone in the community.

The world is going through a very difficult time. We see injustice and
inequality almost everywhere. And yet, those who can influence the world
for good remain a mute spectator as it doesn't affect them.

It takes guts to stand against the tyranny of those in power. Thanks for
standing up for the weak. Proud to be a Django lover.

Thanks and Regards
Just another human being.

-- 
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/CAMwy6_1u0NLp8-okpAak0Hy%2BnSzAv47dpmd8%2B4tE-BSE-M6AwA%40mail.gmail.com.

Re: Django project to run on nodes independently for data entry and sync with server when possible

[Adam Johnson]

Hi!

I think you've found the wrong mailing list for this post. This mailing
list is for discussing the development of Django itself, not for support
using Django. This means the discussions of bugs and features in Django
itself, rather than in your code using it. People on this list are unlikely
to answer your support query with their limited time and energy.

For support, please follow the "Getting Help" page:
https://docs.djangoproject.com/en/3.0/faq/help/ . This will help you find
people who are willing to support you, and to ask your question in a way
that makes it easy for them to answer.

Thanks for your understanding and all the best,

Adam

On Sun, 28 Jun 2020 at 05:52, BRAJESH KUMAR 
wrote:

> Hi,
>
>
>
> I am trying to develop a webpage which should be able to run based on a
> database (MySQL preferred) . the problem I am facing is to handle the
> situation at node computers where data entry is being done, if the internet
> is down, could it save a local copy of the database and allow to merge with
> the server copy once the network is available.
>
>
>
> Regards,
>
> Brajesh
>
> --
> 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/7196EF45-4DD3-4870-8DD8-CF0999619046%40hxcore.ol
> 
> .
>


-- 
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/CAMyDDM0v00VgDAF6q%2BvGdrsE%3D7e3B7trY5cm_nZDnOh4GP9cdQ%40mail.gmail.com.