Re: GSoC 2020 Proposal for ModelStates in Migrations

[Sanskar Jaiswal]

Hey Simon,

Thank you for your feedback! It helps a lot. I shall look into your doubts
right now, and edit my proposal accordingly.

Kind regards
Sanskar

On Tue, Mar 24, 2020 at 3:37 AM charettes  wrote:

> Hello Sanskar,
>
> Thank you for your submission, from a quick look it seems to be heading in
> the right direction.
>
> Would it be possible to break the large overview section into more
> granular sections where you describe how you roughly plan to tackle each of
> the point mention?
>
> I personally have doubts about your desire to make minimal change to the
> schema editor and offload the logic to database_forwards instead of the
> other way around. That doesn't seem to be in line with a future deprecation
> of support for direct model passing. I'd much rather see us move all
> methods to (project_state, model_state, *other_state,
> **other_fields_and_flags) signatures and provide helpers to help
> third-party backends migrate (e.g. a method decorator that renders mode)
> then embedding logic for both paths in the schema editor and adding schema
> specific logic to Operation.database_forwards.
>
> Simon
>
> Le lundi 23 mars 2020 12:59:55 UTC-4, Sanskar Jaiswal a écrit :
>>
>> Hey everyone,
>>
>> Here is my proposal for GSoC. My project is based upon making use of
>> ModelState during the migrated phase of the project, rather than rendering
>> fake Models.
>>
>> https://gist.github.com/aryan9600/b1c2eaf445006c17e02e7677cf1098d5
>>
>> Feedback and criticism is highly appreciated.
>>
>> Thanks!
>> Kind regards
>> Sanskar
>>
> --
> 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/8e9a5959-d677-456f-9bb8-953e68162562%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/CACzaa%3DEr5A543%2B9T6M87Hm9cVVO-h2mbSroV90%3DCp1NCZ%2BwNPw%40mail.gmail.com.

Re: GSoC 2020 Proposal for ModelStates in Migrations

[Javier Buzzi]

Understood. Thanks.

On Monday, March 23, 2020 at 5:48:43 PM UTC-4, charettes wrote:
>
> Javier
>
> > I don't see how this solves anything. At the end of the day these "real" 
> models, or at the very least, not "fake" models will not have any custom 
> queryset/manager/properties/
> method you add to it. Can you explain what it is you're trying to 
> accomplish?
>
> I don't think that's the goal of the project in the first place.
>
> To me the abstract section clearly highlights why this is useful. Right 
> now the schema editor requires access to *rendered* model classes which is 
> quite slow as it involves dynamically creating (or recreating) Python 
> classes and all its dependency chain on most alterations during migration 
> application.
>
> It's way cheaper to create and alter ModelState instances (simple class 
> instances) than creating classes hierarchy over and over again.
>
>
> Le lundi 23 mars 2020 17:14:04 UTC-4, Javier Buzzi a écrit :
>>
>> I don't see how this solves anything. At the end of the day these "real" 
>> models, or at the very least, not "fake" models will not have any custom 
>> queryset/manager/properties/method you add to it. Can you explain what it 
>> is you're trying to accomplish?
>>
>> On Monday, March 23, 2020 at 12:59:55 PM UTC-4, Sanskar Jaiswal wrote:
>>>
>>> Hey everyone,
>>>
>>> Here is my proposal for GSoC. My project is based upon making use of 
>>> ModelState during the migrated phase of the project, rather than rendering 
>>> fake Models.
>>>
>>> https://gist.github.com/aryan9600/b1c2eaf445006c17e02e7677cf1098d5
>>>
>>> Feedback and criticism is highly appreciated.
>>>
>>> Thanks!
>>> Kind regards
>>> Sanskar
>>>
>>

-- 
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/bab34155-12b8-41fb-b58f-009042089e9c%40googlegroups.com.

Re: GSoC 2020 Proposal for ModelStates in Migrations

[charettes]

Hello Sanskar,

Thank you for your submission, from a quick look it seems to be heading in 
the right direction.

Would it be possible to break the large overview section into more granular 
sections where you describe how you roughly plan to tackle each of the 
point mention?

I personally have doubts about your desire to make minimal change to the 
schema editor and offload the logic to database_forwards instead of the 
other way around. That doesn't seem to be in line with a future deprecation 
of support for direct model passing. I'd much rather see us move all 
methods to (project_state, model_state, *other_state, 
**other_fields_and_flags) signatures and provide helpers to help 
third-party backends migrate (e.g. a method decorator that renders mode) 
then embedding logic for both paths in the schema editor and adding schema 
specific logic to Operation.database_forwards.

Simon

Le lundi 23 mars 2020 12:59:55 UTC-4, Sanskar Jaiswal a écrit :
>
> Hey everyone,
>
> Here is my proposal for GSoC. My project is based upon making use of 
> ModelState during the migrated phase of the project, rather than rendering 
> fake Models.
>
> https://gist.github.com/aryan9600/b1c2eaf445006c17e02e7677cf1098d5
>
> Feedback and criticism is highly appreciated.
>
> Thanks!
> Kind regards
> Sanskar
>

-- 
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/8e9a5959-d677-456f-9bb8-953e68162562%40googlegroups.com.

Re: GSoC 2020 Proposal for ModelStates in Migrations

[Sanskar Jaiswal]

Hey Javier!

So currently, during migrations, specifically during the state_forwards and
database_forwards methods, Django renders a fake model and passes it down
to the SchemEditor which is an expensive operation and slows down the
process. The idea is to use ModelStates instead of Models, as their reduced
API make them much more efficient.

The initial problem was filed in this ticket:
code.djangoproject.com/ticket/29898

Kind regards
Sanskar

On Tue, 24 Mar 2020 at 02:44, Javier Buzzi  wrote:

> I don't see how this solves anything. At the end of the day these "real"
> models, or at the very least, not "fake" models will not have any custom
> queryset/manager/properties/method you add to it. Can you explain what it
> is you're trying to accomplish?
>
>
> On Monday, March 23, 2020 at 12:59:55 PM UTC-4, Sanskar Jaiswal wrote:
>>
>> Hey everyone,
>>
>> Here is my proposal for GSoC. My project is based upon making use of
>> ModelState during the migrated phase of the project, rather than rendering
>> fake Models.
>>
>> https://gist.github.com/aryan9600/b1c2eaf445006c17e02e7677cf1098d5
>>
>> Feedback and criticism is highly appreciated.
>>
>> Thanks!
>> Kind regards
>> Sanskar
>>
> --
> 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/3509e4d0-e99c-4ff3-a4d0-45a5c3a988e3%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/CACzaa%3DHxwPZ8ODQX%2BnaP8R0%3DWKk-9NapNbzssWK7spJWO1xt8g%40mail.gmail.com.

Re: GSoC 2020 Proposal for ModelStates in Migrations

[charettes]

Javier

> I don't see how this solves anything. At the end of the day these "real" 
models, or at the very least, not "fake" models will not have any custom 
queryset/manager/properties/
method you add to it. Can you explain what it is you're trying to 
accomplish?

I don't think that's the goal of the project in the first place.

To me the abstract section clearly highlights why this is useful. Right now 
the schema editor requires access to *rendered* model classes which is 
quite slow as it involves dynamically creating (or recreating) Python 
classes and all its dependency chain on most alterations during migration 
application.

It's way cheaper to create and alter ModelState instances (simple class 
instances) than creating classes hierarchy over and over again.


Le lundi 23 mars 2020 17:14:04 UTC-4, Javier Buzzi a écrit :
>
> I don't see how this solves anything. At the end of the day these "real" 
> models, or at the very least, not "fake" models will not have any custom 
> queryset/manager/properties/method you add to it. Can you explain what it 
> is you're trying to accomplish?
>
> On Monday, March 23, 2020 at 12:59:55 PM UTC-4, Sanskar Jaiswal wrote:
>>
>> Hey everyone,
>>
>> Here is my proposal for GSoC. My project is based upon making use of 
>> ModelState during the migrated phase of the project, rather than rendering 
>> fake Models.
>>
>> https://gist.github.com/aryan9600/b1c2eaf445006c17e02e7677cf1098d5
>>
>> Feedback and criticism is highly appreciated.
>>
>> Thanks!
>> Kind regards
>> Sanskar
>>
>

-- 
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/1ad19db8-37d3-4307-b8d4-aecd9b6fd105%40googlegroups.com.

Re: Threads and db connection handling question

[Kartik Sharma]

So in the end, i have to manually close the database connection after my 
threads in my threadpool are done executing, even though, django created 
them automatically when the threads were first created? This is just plain 
bad design.

On Tuesday, June 21, 2016 at 6:04:11 PM UTC+5:30, Aymeric Augustin wrote:
>
> On 21 Jun 2016, at 12:53, Marcin Nowak > 
> wrote:
>
> It looks like it is completely unreliable in async environment, and the 
> worst thing is that I can't force Django to create new connection within 
> the thread/process.
>
> Well, they'll say that Django is not designed for that cases. Maybe. My 
> advise - don't use Django for medium and big projects.
>
>
> Hello Marcin,
>
> I fail to see how you get from “I’m having trouble using an async 
> framework with Django” to “Django only works for small projects”. Indeed, 
> using Django in an “async” context requires special care, until channels 
> land — quotes around “async” because I don’t know whether you’re talking 
> about gevent or asyncio or something else.
>
> However, I know multiple Django-based projects containing millions of 
> lines of codes that took hundreds of man.years to build, maintained by 
> dozens of developers. That works fine. There’s no fundamental reason making 
> Django unsuitable for such projects. It tends to scale better than other 
> technologies thanks to strong conventions and limited use of magic.
>
> Regarding database connections, if you weren’t using Django, you’d have to 
> create a database connection with something like `psycopg2.connect()` and 
> dispose of it with `connection.close()` when you no longer need it. When 
> you’re using the Django ORM, database connections are opened automatically 
> when needed. You still have to close them manually if you aren’t working 
> within the traditional request-response cycle.
>
> If the implicit connection establishment is causing trouble, it shouldn’t 
> be hard to write a custom database backend that doesn’t have this behavior. 
> You would add a method to establish a connection and raise an exception in 
> connection.get_new_connection() 
> 
>  if 
> the connection is already established.
>
> You’re writing that you can’t force Django to create a new connection. 
> That’s as simple as connection.ensure_connection() 
> ,
>  
> possibly after connection.close() 
> 
>  if 
> you want to close a pre-existing connection. ensure_connection() is a 
> private API, but you’re already in unsupported territory if you’re running 
> Django within an async framework, so that isn’t making your situation 
> significantly worse.
>
> Spreading FUD about Django’s supposed unsuitability for non-trivial 
> projects isn’t going to help with your issues and isn’t going to create a 
> context where people will look forward to helping you, so please consider 
> avoiding gratuitous attacks if you need further help.
>
> Best regards,
>
> -- 
> Aymeric.
>
>

-- 
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/d6eddc53-fa1a-4be4-94b8-a76fc8e04d0b%40googlegroups.com.

Re: [GSoC 2020] Secrets Manager Proposal

[Abhirav Dilip Kariya]

Hi,

Thank you for sharing that.

I see what you mean. I can definitely benefit from this during the 
implementation phase, that is, if I’m given the opportunity to work on this.

Thanks 

-- 
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/628a25ac-8a55-4336-a20f-30027be98103%40googlegroups.com.

Re: GSoC 2020 Proposal for ModelStates in Migrations

[Javier Buzzi]

I don't see how this solves anything. At the end of the day these "real" 
models, or at the very least, not "fake" models will not have any custom 
queryset/manager/properties/method you add to it. Can you explain what it 
is you're trying to accomplish?

On Monday, March 23, 2020 at 12:59:55 PM UTC-4, Sanskar Jaiswal wrote:
>
> Hey everyone,
>
> Here is my proposal for GSoC. My project is based upon making use of 
> ModelState during the migrated phase of the project, rather than rendering 
> fake Models.
>
> https://gist.github.com/aryan9600/b1c2eaf445006c17e02e7677cf1098d5
>
> Feedback and criticism is highly appreciated.
>
> Thanks!
> Kind regards
> Sanskar
>

-- 
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/3509e4d0-e99c-4ff3-a4d0-45a5c3a988e3%40googlegroups.com.

Re: Fellow Reports - March 2020

[Mariusz Felisiak]

Week ending March 22, 2020.

*Triaged:*
https://code.djangoproject.com/ticket/31366 - GEOSGeometry fails on 
instance with GEOJson and srid not 4326. (invalid)
https://code.djangoproject.com/ticket/31367 - ImportError error while 
importing class from auth/mixin to auth/view. (wontfix)
https://code.djangoproject.com/ticket/31368 - Document 
Field.from_db_value()'s "expression" parameter. (accepted)
https://code.djangoproject.com/ticket/31370 - Make parallel test runner 
work with buffer option. (accepted)
https://code.djangoproject.com/ticket/31374 - Runtime Error unable to solve 
from forums/ FAQ. (invalid)
https://code.djangoproject.com/ticket/31372 - Autoreload: dictionary 
changed size during iteration. (wontfix)
https://code.djangoproject.com/ticket/31376 - Avoid unnecessary null checks 
ordering when possible on database that don't support NULLS (FIRST|LAST). 
(accepted)
https://code.djangoproject.com/ticket/31324 - Filter JSONField using 
`=None`. (wontfix)
https://code.djangoproject.com/ticket/31379 - Admin login page is broken 
after using django-admin startproject. (worksforme)
https://code.djangoproject.com/ticket/31378 - Support bytes in 
assertXMLEqual()/assertXMLNotEqual(). (wontfix)
https://code.djangoproject.com/ticket/31381 - jsi18n with zh-hans (or 
zh-hant) not working. (invalid)
https://code.djangoproject.com/ticket/11836 - Missing 
django.forms.widgets.MultiWidget hidden counterpart. (wontfix)
https://code.djangoproject.com/ticket/31389 - Django SQLite3 ExtractWeek 
returns week one instead of the last week of the year. (invalid)
https://code.djangoproject.com/ticket/31391 - Remove cancel.js dependency 
on jQuery. (accepted)
https://code.djangoproject.com/ticket/31388 - HttpResponseBase.setdefault() 
issue. (invalid)
https://code.djangoproject.com/ticket/31387 - Document BASE_DIR setting. 
(invalid)
https://code.djangoproject.com/ticket/31393 - Support table SQL comments. 
(duplicate)

*Reviewed/committed:*
https://github.com/django/django/pull/12564 - Fixed #31361 -- Fixed invalid 
action="" in admin forms.
https://github.com/django/django/pull/12568 - Fixed #31363 -- Added support 
for negative integers to intword template filter.
https://github.com/django/django/pull/12525 - Fixed #31340 -- Allowed query 
expressions in SearchQuery.value and __search lookup.
https://github.com/django/django/pull/12583 - Fixed #31376 -- Optimized 
nulls ordering when possible on SQLite and MySQL.
https://github.com/django/django/pull/12581 - Fixed #31371 -- Increased 
User.first_name max_length to 150 characters.
https://github.com/django/django/pull/12582 - Fixed #31368 -- Doc'd 
'expression' parameter of Field.from_db_value()/Expression.convert_value().
https://github.com/django/django/pull/11650 - Fixed #31224 -- Added support 
for asynchronous views and middleware.
https://github.com/django/django/pull/12558 - Fixed #31123 -- Added 
--include-stale-apps option to the remove_stale_contenttypes management 
command.
https://github.com/django/django/pull/12470 - Fixed #31285 -- Fixed 
inherited Meta.ordering of "-pk".
https://github.com/django/django/pull/12459 - Fixed #31144 -- Relaxed 
system check for max_length of CharFields on MySQL/MariaDB by turning into 
a warning.
https://github.com/django/django/pull/12593 - Refs #29724 -- Added is_dst 
parameter to QuerySet.datetimes().

*Authored:*
https://github.com/django/django/pull/12584 - Refs #31055 -- Made long 
column names checks support databases aware.
https://github.com/django/django/pull/12585 - Refs #29548 -- Mentioned 
MariaDB in database system checks.

Best regards,
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/ac648d59-3e0f-45b2-9786-2f43493ce087%40googlegroups.com.

GSoC Proposal to extend the parallel test runner to Windows and macOS and to support Oracle parallel test running

[Ahmad A. Hussein]

Django's parallel test runner works through forking processes, making it 
incompatible on Windows by default and incompatible in macOS due to a 
recent update. Windows and macOS both support spawn and have it enabled by 
default. Databases are cloned for each worker.

To switch from fork to spawn, state setup will be handled by spawned 
processes instead of through inheritance via fork. Worker’s connections to 
databases can still be done through get_test_db_clone_settings which 
changes the names of databases assigned to a specific worker_id; however, 
SQLite's cloning method is incompatible with spawn. 


SQLite’s cloning method relies on it both being in-memory and fork as when 
we fork the main process, we retain SQLite's in-memory database in the 
child process. The solution is to get a SQL dump of the database and throw 
it into the target cloned databases. This is also the established standard 
in handling MySQL’s cloning process. Both Postgresql's and MySQL's cloning 
methods are independent of fork or spawn and won't require any modification.


Oracle has not been implemented in the parallel test runner originally even 
on Linux and I propose to extend support to Oracle as well in my proposal. 
I want to confirm if there is significant support behind this as a feature 
or not before I commit to writing a specification, but as a summary it is 
definitely possible as the work collaborated on by Aymeric Augustin and 
Shai Berger show that cloning CAN be done through multiple ideas. The 
reason why it's a headache is that Oracle does not support separate 
databases under a single user- unlike our other supported databases, so we 
can't clone databases without introducing another user. Some methods may 
also need to be rewritten to accommodate for the Oracle backend, but that 
isn't an issue. I've glossed over writing out a schedule or a more detailed 
abstract as I I'm mainly posting here to see if there is indeed support for 
the Oracle proposal and to make sure I am not missing any details in 
regards to adapting the current parallel test runner to work through spawn. 
Let me know what you think.


Regards,

Ahmad

-- 
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/317f67c6-4b23-483f-ada5-9bdbb45d0997%40googlegroups.com.

Re: [GSoC 2020] Secrets Manager Proposal

[Peter Baumgartner]

You might find https://github.com/lincolnloop/goodconf interesting. I
see some overlap there with what you're doing.

On Mon, Mar 23, 2020 at 9:43 AM Abhirav Dilip Kariya
 wrote:
>
> Hi,
>
> Thank your for the suggestion.
>
> I did look at some libraries. However, the libraries I looked into (or  
> rather, was able to find) only dealt with single type of secrets store. Like 
> django-environ only deals with .env files.
>
> Please let me know if you have any libraries in mind.
>
> Thanks
>
> --
> 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/c6409dde-3390-4cc3-9769-fc4ba08b4a98%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/CAC6K9z%3D7UBUvLi%2Be%3D9Dy1NFBJ4nX3Yqy4%2Bdjxw9Jc1rjthoWiQ%40mail.gmail.com.

GSoC 2020 Proposal for ModelStates in Migrations

[Sanskar Jaiswal]

Hey everyone,

Here is my proposal for GSoC. My project is based upon making use of
ModelState during the migrated phase of the project, rather than rendering
fake Models.

https://gist.github.com/aryan9600/b1c2eaf445006c17e02e7677cf1098d5

Feedback and criticism is highly appreciated.

Thanks!
Kind regards
Sanskar

-- 
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/CACzaa%3DEj16ZMeReQsAcekZvGi28531Am62no50sM19bjH2pAsw%40mail.gmail.com.

Re: [GSoC 2020] Secrets Manager Proposal

[Abhirav Dilip Kariya]

Hi,

Thank your for the suggestion.

I did look at some libraries. However, the libraries I looked into (or  rather, 
was able to find) only dealt with single type of secrets store. Like 
django-environ only deals with .env files. 

Please let me know if you have any libraries in mind.

Thanks

-- 
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/c6409dde-3390-4cc3-9769-fc4ba08b4a98%40googlegroups.com.

Re: [GSoC 2020] Secrets Manager Proposal

[Caio Ariede]

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 at Django's Wiki for GSoC 2020 
> . 
> 
> Here is the link to my proposal: GSoC Proposal 
> 
> Link to Prototype Gist 
> 
> Link to Prototype 
> 
> Please let me know if you get the time to go through it and have any feedback 
> for me.
> 
> 
> 
> Thanks in advance,
> Abhirav Dilip Kariya
> 
> 
> -- 
> 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/9c418579-f5c9-402e-8ae9-68b42290224c%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/2D19D91E-0F9D-42DD-A1B5-CBC1FA0508AA%40gmail.com.

Re: [Feature Request] Having an middleware to be able to force authentication on views by default

[Mehmet Ince]

Hi Ahmad,

> On 23 Mar 2020, at 13:23, Ahmad A. Hussein  wrote:
> 
> I completely agree with what has already been said by everyone here; 
> moreover, this is a battery missing from Django in my opinion. It would make 
> Django more "batteries-included" if this was part of core rather than third 
> party-libraries. If you need help with documentation, I can definitely throw 
> a hand.

Thank you very much. I definitely going to need a help with documentation !

Also, thank you very much for everyone who’s involved to the discussion. It's 
great to see that everyone is supporting to have this in django-core.

As far as I can see, we have a common ground about following items.

- Creating a LoginRequiredAuthenticationMiddleware class which extends our 
current AuthenticationMiddleware class.
- Creating @login_not_required decorator and LoginNotRequiredMixin class. They 
won’t do anything, but marking views as a ’not login required for that 
endpoint’ so that our middleware can pass the request.
- We have some default views within auth/views such as, LoginView, 
redirect_to_login and PasswordResetView. They must use our new decorator or 
Mixin.

PS: I like those names by the way. Thanks for func and class name suggestions 
Adam.

One thing that isn’t clear for me is URL exclusions list in settings.py. @Matt 
Magin and @Hanne Moa has mentioned about it. It’s basically a list of url 
and/or regex that exempt the view from login validation.

I truly understand that such a list can be very useful. But I personally don’t 
support adding that functionality. Because, I believe people will use wildcard 
rules, like LOGIN_EXEMPT_URL = ['/api/*'], which will disables the protection 
we are trying to put in the first place.

Maybe even package maintainers will use a wide range of rule definitions in 
their own settings file in order to make their package compatible with 
Django-core release. I think that kind of compatibility issue should be 
addressed by 3rd party package maintainers.

> 
> 
> Regards,
> Ahmad
> 
> --
> 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/ef6ad79b-e37b-46b3-87c3-60d7c97e5395%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/3ECF27A7-9308-4CAF-94DC-1A78DC411F82%40mehmetince.net.


signature.asc
Description: Message signed with OpenPGP

Re: On adding comments to database schema

[SoungRyoul Kim]

i assign it to me
https://code.djangoproject.com/ticket/18468 


i will close this pullRequest caused by imperfection
​https://github.com/django/django/pull/12605

I will bring a new PullRequest as soon as possible.

in at least a week

-- 
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/8f343f6f-3ecb-4c3e-b8f6-7c9018480505%40googlegroups.com.

Re: [Feature Request] Having an middleware to be able to force authentication on views by default

[Ahmad A. Hussein]

I completely agree with what has already been said by everyone here; 
moreover, this is a battery missing from Django in my opinion. It would 
make Django more "batteries-included" if this was part of core rather than 
third party-libraries. If you need help with documentation, I can 
definitely throw a hand.


Regards,
Ahmad

-- 
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/ef6ad79b-e37b-46b3-87c3-60d7c97e5395%40googlegroups.com.