Re: GSoC Proposal: Add Cross-DB JSONField, ArrayField, and HStoreField

[Asif Saif Uddin]

You can open a work in progress pr to fix them one by one gradually and 
trying to fix some of them will give you a much better understanding of 
django orm internals as it is considered the most complex part of the 
framework. This will also improve your chance to represent yourself as a 
much stronger candidate and you will be able to interact with the community 
in a very meaningful way. Just my 2 cents. 

On Sunday, April 7, 2019 at 12:27:51 PM UTC+6, Sage M.A. wrote:
>
> Oh, I forgot, one of them is not related to datetime functions: 
> test_unsupported_backend.
>
> On Sunday, 7 April 2019 13:26:10 UTC+7, Sage M.A. wrote:
>>
>> Hi Asif,
>> That's a good idea! I've installed the latest stable release of MariaDB 
>> (10.3.14) on my machine and ran Django test suits with it.
>> The results 
>>  (I've 
>> truncated them to only contain the failures and errors) show 19 failures 
>> and 15 errors, all of which seem to be
>> related to datetime functions. I suppose that'll be enough for me to work 
>> on if my GSoC project finishes early. I'll also need to
>> write docs about the new support for MariaDB.
>>
>> On a side note, setting up and destroying the database for the test took 
>> hours on my machine. Is that normal? I had to use
>> verbosity=2 to find out that it was not freezing, just really slow.
>>
>> On Saturday, 6 April 2019 22:32:53 UTC+7, Asif Saif Uddin wrote:
>>>
>>> Sage, regarding MariaDB, I have a little suggestion with you. If you 
>>> could setup a latest version of mariadb locally and try to run Django test 
>>> suits with that, you might have some ideas of remaining issues analyzing 
>>> the test failures initially.
>>>
>>> On Thursday, April 4, 2019 at 11:30:48 AM UTC+6, Sage M.A. wrote:

 Hi, Carlton.

 Thanks a lot for the feedback!
 Ah, yes, looks like I missed that Oracle implementation. I've updated 
 my proposal accordingly.
 To summarize:

- Added info about Oracle implementation (see 1.1)
- Replaced 1 week of research with 1 week of writing tests and docs 
for POC SQLite JSONField (see 3.1.1 and 3.1.2)
- Replaced the idea of implementing HStoreField with writing 
documentation for ArrayField, migration path, and SQLite+JSON1 (see 
 3.3.2)
- Took half a week from the merging process into writing the 
aforementioned docs.
- Wrote about the possibility of merging the first and second 
milestones so the final milestone would not be so big to merge. (see 
 3.1.2 
and 3.2.2)
- Wrote about the possibility of finishing the project early (see 
3.4)

 About #29548 , it seems 
 interesting to me but I'm not quite sure what's left to be done.

 Regards,
 Sage

 On Wednesday, 3 April 2019 21:40:09 UTC+7, Carlton Gibson wrote:
>
> Hi Sage. 
>
> Thanks for the proposal. It's looking OK. Couple of points: 
>
>
>- There IS an Oracle implementation. See the ticket here: 
>https://code.djangoproject.com/ticket/29821
>- Something that looks like an ArrayField, yes. HStore... not so 
>sure it's worth mimicking. 
>- On the timeline: I think you've spread the coding bit too thin 
>and not allocated enough for Documenting.
>   - I think you if you want full-guns at the SQLite PoC in week 1 
>   and 2 you'd have something in place quite quickly. 
>  - The base field should be simple enough™
>  - The SQLite only lookups shouldn't be too complicated. 
>   - As I commented on the other thread on this topic, we'll need 
>   to advise on getting people set up with SQLite with the JSON 
> extension. 
>   - There's more in this that you think I'd guess. No harm in 
>  putting time in the schedule for it. 
>   - Allow for the possibility you complete early and have time to 
>   work on other things...
>   - This stuff is difficult to get right. It's more balance that 
>   exact times: 
>  - The actual timeline won't match the plan ever. 
>  - you don't need to worry about two days off for holiday 🙂
>   
> Your contributions so far have been super. Thank you. 
>
> Kind Regards,
>
> Carlton
>
>
> On Tuesday, 2 April 2019 13:41:37 UTC+2, Sage M.A. wrote:
>>
>> Hello, everyone! My name is Sage. I'm a 19-year-old computer science 
>> student from Indonesia. I'm planning to join the Google Summer of Code 
>> (GSoC) this year, and I want to contribute to Django. I have written a 
>> draft for my proposal in this gist 
>> . 
>> I have submitted two small patches for Django, and I hope to contribute 
>

Re: GSOC Proposal (Bundler for Django)

[Kiran Capoor]

Yes, as a personal project sure thing. If you need help ask on django users
or respective forum. Contributing to Open Source doesn't really mean to
start with GSoC. Start with a pet project and keep working on it.
Good luck!

Regards,
Kiran Capoor

On Sun, Apr 7, 2019 at 8:10 AM Ashik Meerankutty 
wrote:

> Can we write our own bundler only for django. Is that good
>
> On Sun, 7 Apr 2019 at 8:04 AM, Ashik Meerankutty 
> wrote:
>
>> Thank you for your feed back.
>>
>> On Sun, 7 Apr 2019 at 12:03 AM, Kiran Capoor 
>> wrote:
>>
>>> Hi,
>>>
>>> This has already been implemented via multiple Third party Projects -
>>>
>>> 1. Django Webpack Loader by owais-
>>> https://github.com/owais/django-webpack-loader
>>>
>>> 2. Cookie-cutter Django Webpack by myself(not production ready though) -
>>> https://github.com/kiran-capoor94/cookiecutter-django-webpack
>>>
>>> Many more are there.
>>>
>>> Also, forcing users to use a bundler like webpack is not really
>>> preferred  by many. Some might want to use gulp, or maybe nothing at all.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Kiran Capoor
>>>
>>>
>>> On Sat, 6 Apr 2019 at 18:33, Ashik Meerankutty 
>>> wrote:
>>>
 Please review and comment my draft proposal for GSOC 2019
 Draft
 

 --
 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 post to this group, send email to django-developers@googlegroups.com
 .
 Visit this group at https://groups.google.com/group/django-developers.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/django-developers/f843803b-3b14-4798-bd31-5948c0fe820a%40googlegroups.com
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>> --
>>> Sent from iPhone
>>>
>>> --
>>> 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 post to this group, send email to django-developers@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/CAANvM2muqw%3D54GWcpUvGTS%2B%2Bgd9nZ1WA0wvaDQRz%3Do3SmXePhw%40mail.gmail.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CALaZoZc6U0TOwYmKL5nKeFVwhQ%2BuMiHSPHX050U%2BdEXWqhwUfA%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Regards,
Kiran Capoor
+91-9969465880

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAANvM2k7A%3Dx9UKEC5eTn48A6%2BRD%3DG%2BfTHRxz4YaubVkidfN8uw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC Proposal: Add Cross-DB JSONField, ArrayField, and HStoreField

[Tim Graham]

MariaDB is supported (see https://code.djangoproject.com/ticket/29548). The 
test failures are (as the error message says) because you haven't installed 
the timezone definitions.

On Sunday, April 7, 2019 at 3:03:14 AM UTC-4, Asif Saif Uddin wrote:
>
> You can open a work in progress pr to fix them one by one gradually and 
> trying to fix some of them will give you a much better understanding of 
> django orm internals as it is considered the most complex part of the 
> framework. This will also improve your chance to represent yourself as a 
> much stronger candidate and you will be able to interact with the community 
> in a very meaningful way. Just my 2 cents. 
>
> On Sunday, April 7, 2019 at 12:27:51 PM UTC+6, Sage M.A. wrote:
>>
>> Oh, I forgot, one of them is not related to datetime functions: 
>> test_unsupported_backend.
>>
>> On Sunday, 7 April 2019 13:26:10 UTC+7, Sage M.A. wrote:
>>>
>>> Hi Asif,
>>> That's a good idea! I've installed the latest stable release of MariaDB 
>>> (10.3.14) on my machine and ran Django test suits with it.
>>> The results 
>>>  (I've 
>>> truncated them to only contain the failures and errors) show 19 failures 
>>> and 15 errors, all of which seem to be
>>> related to datetime functions. I suppose that'll be enough for me to 
>>> work on if my GSoC project finishes early. I'll also need to
>>> write docs about the new support for MariaDB.
>>>
>>> On a side note, setting up and destroying the database for the test took 
>>> hours on my machine. Is that normal? I had to use
>>> verbosity=2 to find out that it was not freezing, just really slow.
>>>
>>> On Saturday, 6 April 2019 22:32:53 UTC+7, Asif Saif Uddin wrote:

 Sage, regarding MariaDB, I have a little suggestion with you. If you 
 could setup a latest version of mariadb locally and try to run Django test 
 suits with that, you might have some ideas of remaining issues analyzing 
 the test failures initially.

 On Thursday, April 4, 2019 at 11:30:48 AM UTC+6, Sage M.A. wrote:
>
> Hi, Carlton.
>
> Thanks a lot for the feedback!
> Ah, yes, looks like I missed that Oracle implementation. I've updated 
> my proposal accordingly.
> To summarize:
>
>- Added info about Oracle implementation (see 1.1)
>- Replaced 1 week of research with 1 week of writing tests and 
>docs for POC SQLite JSONField (see 3.1.1 and 3.1.2)
>- Replaced the idea of implementing HStoreField with writing 
>documentation for ArrayField, migration path, and SQLite+JSON1 (see 
> 3.3.2)
>- Took half a week from the merging process into writing the 
>aforementioned docs.
>- Wrote about the possibility of merging the first and second 
>milestones so the final milestone would not be so big to merge. (see 
> 3.1.2 
>and 3.2.2)
>- Wrote about the possibility of finishing the project early (see 
>3.4)
>
> About #29548 , it seems 
> interesting to me but I'm not quite sure what's left to be done.
>
> Regards,
> Sage
>
> On Wednesday, 3 April 2019 21:40:09 UTC+7, Carlton Gibson wrote:
>>
>> Hi Sage. 
>>
>> Thanks for the proposal. It's looking OK. Couple of points: 
>>
>>
>>- There IS an Oracle implementation. See the ticket here: 
>>https://code.djangoproject.com/ticket/29821
>>- Something that looks like an ArrayField, yes. HStore... not so 
>>sure it's worth mimicking. 
>>- On the timeline: I think you've spread the coding bit too thin 
>>and not allocated enough for Documenting.
>>   - I think you if you want full-guns at the SQLite PoC in week 
>>   1 and 2 you'd have something in place quite quickly. 
>>  - The base field should be simple enough™
>>  - The SQLite only lookups shouldn't be too complicated. 
>>   - As I commented on the other thread on this topic, we'll need 
>>   to advise on getting people set up with SQLite with the JSON 
>> extension. 
>>   - There's more in this that you think I'd guess. No harm in 
>>  putting time in the schedule for it. 
>>   - Allow for the possibility you complete early and have time 
>>   to work on other things...
>>   - This stuff is difficult to get right. It's more balance that 
>>   exact times: 
>>  - The actual timeline won't match the plan ever. 
>>  - you don't need to worry about two days off for holiday 🙂
>>   
>> Your contributions so far have been super. Thank you. 
>>
>> Kind Regards,
>>
>> Carlton
>>
>>
>> On Tuesday, 2 April 2019 13:41:37 UTC+2, Sage M.A. wrote:
>>>
>>> Hello, everyone! My name is Sage. I'm a 19-year-old computer science 

Re: Should we backport adding support for psycopg2 2.8 to the 1.11.x and 2.1.x?

[Mariusz Felisiak]

Django 2.0 is no longer supported.

W dniu sobota, 6 kwietnia 2019 18:52:21 UTC+2 użytkownik Uri Even-Chen 
napisał:
>
> Don't forget 2.0.
>
> I updated my project to use psycopg2==2.7.7 until we upgrade to Django 2.2.
>
> אורי
> u...@speedy.net 
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3b65b077-13b5-4641-85d8-a3cc7fe140a8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC Proposal: Add Cross-DB JSONField, ArrayField, and HStoreField

[Sage M.A.]

Thanks for the information Asif, but it turns out Django already supports 
MariaDB.

On Sunday, 7 April 2019 14:03:14 UTC+7, Asif Saif Uddin wrote:
>
> You can open a work in progress pr to fix them one by one gradually and 
> trying to fix some of them will give you a much better understanding of 
> django orm internals as it is considered the most complex part of the 
> framework. This will also improve your chance to represent yourself as a 
> much stronger candidate and you will be able to interact with the community 
> in a very meaningful way. Just my 2 cents. 
>
> On Sunday, April 7, 2019 at 12:27:51 PM UTC+6, Sage M.A. wrote:
>>
>> Oh, I forgot, one of them is not related to datetime functions: 
>> test_unsupported_backend.
>>
>> On Sunday, 7 April 2019 13:26:10 UTC+7, Sage M.A. wrote:
>>>
>>> Hi Asif,
>>> That's a good idea! I've installed the latest stable release of MariaDB 
>>> (10.3.14) on my machine and ran Django test suits with it.
>>> The results 
>>>  (I've 
>>> truncated them to only contain the failures and errors) show 19 failures 
>>> and 15 errors, all of which seem to be
>>> related to datetime functions. I suppose that'll be enough for me to 
>>> work on if my GSoC project finishes early. I'll also need to
>>> write docs about the new support for MariaDB.
>>>
>>> On a side note, setting up and destroying the database for the test took 
>>> hours on my machine. Is that normal? I had to use
>>> verbosity=2 to find out that it was not freezing, just really slow.
>>>
>>> On Saturday, 6 April 2019 22:32:53 UTC+7, Asif Saif Uddin wrote:

 Sage, regarding MariaDB, I have a little suggestion with you. If you 
 could setup a latest version of mariadb locally and try to run Django test 
 suits with that, you might have some ideas of remaining issues analyzing 
 the test failures initially.

 On Thursday, April 4, 2019 at 11:30:48 AM UTC+6, Sage M.A. wrote:
>
> Hi, Carlton.
>
> Thanks a lot for the feedback!
> Ah, yes, looks like I missed that Oracle implementation. I've updated 
> my proposal accordingly.
> To summarize:
>
>- Added info about Oracle implementation (see 1.1)
>- Replaced 1 week of research with 1 week of writing tests and 
>docs for POC SQLite JSONField (see 3.1.1 and 3.1.2)
>- Replaced the idea of implementing HStoreField with writing 
>documentation for ArrayField, migration path, and SQLite+JSON1 (see 
> 3.3.2)
>- Took half a week from the merging process into writing the 
>aforementioned docs.
>- Wrote about the possibility of merging the first and second 
>milestones so the final milestone would not be so big to merge. (see 
> 3.1.2 
>and 3.2.2)
>- Wrote about the possibility of finishing the project early (see 
>3.4)
>
> About #29548 , it seems 
> interesting to me but I'm not quite sure what's left to be done.
>
> Regards,
> Sage
>
> On Wednesday, 3 April 2019 21:40:09 UTC+7, Carlton Gibson wrote:
>>
>> Hi Sage. 
>>
>> Thanks for the proposal. It's looking OK. Couple of points: 
>>
>>
>>- There IS an Oracle implementation. See the ticket here: 
>>https://code.djangoproject.com/ticket/29821
>>- Something that looks like an ArrayField, yes. HStore... not so 
>>sure it's worth mimicking. 
>>- On the timeline: I think you've spread the coding bit too thin 
>>and not allocated enough for Documenting.
>>   - I think you if you want full-guns at the SQLite PoC in week 
>>   1 and 2 you'd have something in place quite quickly. 
>>  - The base field should be simple enough™
>>  - The SQLite only lookups shouldn't be too complicated. 
>>   - As I commented on the other thread on this topic, we'll need 
>>   to advise on getting people set up with SQLite with the JSON 
>> extension. 
>>   - There's more in this that you think I'd guess. No harm in 
>>  putting time in the schedule for it. 
>>   - Allow for the possibility you complete early and have time 
>>   to work on other things...
>>   - This stuff is difficult to get right. It's more balance that 
>>   exact times: 
>>  - The actual timeline won't match the plan ever. 
>>  - you don't need to worry about two days off for holiday 🙂
>>   
>> Your contributions so far have been super. Thank you. 
>>
>> Kind Regards,
>>
>> Carlton
>>
>>
>> On Tuesday, 2 April 2019 13:41:37 UTC+2, Sage M.A. wrote:
>>>
>>> Hello, everyone! My name is Sage. I'm a 19-year-old computer science 
>>> student from Indonesia. I'm planning to join the Google Summer of Code 
>>> (GSoC) this ye

Re: GSoC Proposal: Add Cross-DB JSONField, ArrayField, and HStoreField

[Sage M.A.]

I see, thanks for the info! Why is the ticket still open, though? Also, I 
still found one failing window test case..

On Sunday, 7 April 2019 16:20:13 UTC+7, Tim Graham wrote:
>
> MariaDB is supported (see https://code.djangoproject.com/ticket/29548). 
> The test failures are (as the error message says) because you haven't 
> installed the timezone definitions.
>
> On Sunday, April 7, 2019 at 3:03:14 AM UTC-4, Asif Saif Uddin wrote:
>>
>> You can open a work in progress pr to fix them one by one gradually and 
>> trying to fix some of them will give you a much better understanding of 
>> django orm internals as it is considered the most complex part of the 
>> framework. This will also improve your chance to represent yourself as a 
>> much stronger candidate and you will be able to interact with the community 
>> in a very meaningful way. Just my 2 cents. 
>>
>> On Sunday, April 7, 2019 at 12:27:51 PM UTC+6, Sage M.A. wrote:
>>>
>>> Oh, I forgot, one of them is not related to datetime functions: 
>>> test_unsupported_backend.
>>>
>>> On Sunday, 7 April 2019 13:26:10 UTC+7, Sage M.A. wrote:

 Hi Asif,
 That's a good idea! I've installed the latest stable release of MariaDB 
 (10.3.14) on my machine and ran Django test suits with it.
 The results 
  (I've 
 truncated them to only contain the failures and errors) show 19 failures 
 and 15 errors, all of which seem to be
 related to datetime functions. I suppose that'll be enough for me to 
 work on if my GSoC project finishes early. I'll also need to
 write docs about the new support for MariaDB.

 On a side note, setting up and destroying the database for the test 
 took hours on my machine. Is that normal? I had to use
 verbosity=2 to find out that it was not freezing, just really slow.

 On Saturday, 6 April 2019 22:32:53 UTC+7, Asif Saif Uddin wrote:
>
> Sage, regarding MariaDB, I have a little suggestion with you. If you 
> could setup a latest version of mariadb locally and try to run Django 
> test 
> suits with that, you might have some ideas of remaining issues analyzing 
> the test failures initially.
>
> On Thursday, April 4, 2019 at 11:30:48 AM UTC+6, Sage M.A. wrote:
>>
>> Hi, Carlton.
>>
>> Thanks a lot for the feedback!
>> Ah, yes, looks like I missed that Oracle implementation. I've updated 
>> my proposal accordingly.
>> To summarize:
>>
>>- Added info about Oracle implementation (see 1.1)
>>- Replaced 1 week of research with 1 week of writing tests and 
>>docs for POC SQLite JSONField (see 3.1.1 and 3.1.2)
>>- Replaced the idea of implementing HStoreField with writing 
>>documentation for ArrayField, migration path, and SQLite+JSON1 (see 
>> 3.3.2)
>>- Took half a week from the merging process into writing the 
>>aforementioned docs.
>>- Wrote about the possibility of merging the first and second 
>>milestones so the final milestone would not be so big to merge. (see 
>> 3.1.2 
>>and 3.2.2)
>>- Wrote about the possibility of finishing the project early (see 
>>3.4)
>>
>> About #29548 , it seems 
>> interesting to me but I'm not quite sure what's left to be done.
>>
>> Regards,
>> Sage
>>
>> On Wednesday, 3 April 2019 21:40:09 UTC+7, Carlton Gibson wrote:
>>>
>>> Hi Sage. 
>>>
>>> Thanks for the proposal. It's looking OK. Couple of points: 
>>>
>>>
>>>- There IS an Oracle implementation. See the ticket here: 
>>>https://code.djangoproject.com/ticket/29821
>>>- Something that looks like an ArrayField, yes. HStore... not so 
>>>sure it's worth mimicking. 
>>>- On the timeline: I think you've spread the coding bit too thin 
>>>and not allocated enough for Documenting.
>>>   - I think you if you want full-guns at the SQLite PoC in week 
>>>   1 and 2 you'd have something in place quite quickly. 
>>>  - The base field should be simple enough™
>>>  - The SQLite only lookups shouldn't be too complicated. 
>>>   - As I commented on the other thread on this topic, we'll 
>>>   need to advise on getting people set up with SQLite with the JSON 
>>>   extension. 
>>>   - There's more in this that you think I'd guess. No harm in 
>>>  putting time in the schedule for it. 
>>>   - Allow for the possibility you complete early and have time 
>>>   to work on other things...
>>>   - This stuff is difficult to get right. It's more balance 
>>>   that exact times: 
>>>  - The actual timeline won't match the plan ever. 
>>>  - you don't need to worry about two days off for holid

Re: GSOC Proposal (Bundler for Django)

[Ashik Meerankutty]

Scot, Thank you for your feedback. Do you have any suggestions?

On Sun, Apr 7, 2019 at 11:11 AM Scot Hacker  wrote:

>
>
> On Saturday, April 6, 2019 at 6:03:29 AM UTC-7, Ashik Meerankutty wrote:
>>
>> Please review and comment my draft proposal for GSOC 2019
>> Draft
>> 
>>
>
> Ashik's proposal is more along the lines of a general asset pipeline, a la
> django-compressor or django-pipeline, rather than a webpack builder.
> Regardless, I count 30+ asset pipeline systems at
> https://djangopackages.org/grids/g/asset-managers/ .
>
> ./s
>
> --
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/cf64fba5-120b-4aae-8b9e-4409783bfe99%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALaZoZcJUFwV0tU3YgL0Gw07O66sNBoDMbeqPJv5hy0B%2BnGyAQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Specifying model relationship as string vs concrete model class

[Mohit Solanki]

I know this group is for django development, posting it here because I want 
to here from core django devs.

On Sunday, April 7, 2019 at 9:23:45 AM UTC+5:30, Mohit Solanki wrote:
>
> Since Django allows specifying relationship between models by both as a 
> string or by a model class
> "models.Foreignkey('User') vs "models.Foreignkey(User)". Which one is 
> preferred and recommend and what are the downsides of choosing one over the 
> other? In documentation all the examples are of the second form but i have 
> seen ppl specifying relationships in string. Can someone please elaborate 
> more on this?
>
> Regards,
> Mohit Solanki
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/50f5ef75-bead-4f4c-89d7-888101322683%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Specifying model relationship as string vs concrete model class

[Collin Anderson]

models.Foreignkey(User) is a more pythonic and allows more better analysis
by tools like flake8, but in some cases you need to create the ForeignKey
before User is defined, so you _have_ to use a string. Example:

https://docs.djangoproject.com/en/stable/ref/models/fields/#foreignkey

On Sat, Apr 6, 2019 at 11:53 PM Mohit Solanki 
wrote:

> Since Django allows specifying relationship between models by both as a
> string or by a model class
> "models.Foreignkey('User') vs "models.Foreignkey(User)". Which one is
> preferred and recommend and what are the downsides of choosing one over the
> other? In documentation all the examples are of the second form but i have
> seen ppl specifying relationships in string. Can someone please elaborate
> more on this?
>
> Regards,
> Mohit Solanki
>
> --
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAKB6Ln-4rU2c%3DZL%3DTCbYfFZWG8fSDq4KP9DYhUc4TDFLNFdQtw%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFO84S6m4aog8bm0gwJ14K4wH4x7o-DsYk1Hf2MqSmic6qgESw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Fellow Reports - April 2019

[Mariusz Felisiak]

Week ending April 7, 2019.

*Triaged:*
https://code.djangoproject.com/ticket/30302 - model_to_dict() should return 
an empty dict for an empty list of fields. (accepted)
https://code.djangoproject.com/ticket/30304 - Support setting Secure, 
HttpOnly, SameSite on the language cookie (accepted)
https://code.djangoproject.com/ticket/30305 - Feature to set the returncode 
of a django custom command (invalid)
https://code.djangoproject.com/ticket/30307 - dbshell doesn't pass password 
properly on Oracle 18c. (accepted)
https://code.djangoproject.com/ticket/30309 - Remove hasattr reference in 
One-to-One documentation example (invalid)
https://code.djangoproject.com/ticket/30315 - StringAgg with ordering in 
subquery generates invalid string_agg() SQL function call (accepted)
https://code.djangoproject.com/ticket/30319 - model.save() surprising 
behavior with update_fields specified and auto_now field in model (wontfix)
https://code.djangoproject.com/ticket/30325 - Inconsistent count() 
behaviour on reverse relations in ManyToManyFields with custom model 
manager (accepted)
https://code.djangoproject.com/ticket/30327 - Failing collectstatic with 
ManifestFilesMixin (invalid)
https://code.djangoproject.com/ticket/30328 - Integer field range 
validators crash when limit_value is callable. (accepted)
https://code.djangoproject.com/ticket/30322 - DEBUG=False + 
csrf_exempt(GraphqlView) + gunicorn == crash (needsinfo)
https://code.djangoproject.com/ticket/30329 - ImproperlyConfigured 
exceptions should be raised immediately. (accepted)
https://code.djangoproject.com/ticket/30330 - delete() on instances of 
models without any dependencies doesn't clear PKs. (accepted)
https://code.djangoproject.com/ticket/30333 - __hash__ is not inherited 
from model.Model if __eq__ is defined (accepted)
https://code.djangoproject.com/ticket/30326 - Document how to avoid F() 
assignments persistence (accepted)
https://code.djangoproject.com/ticket/30321 - Add example to 
Form.changed_data (accepted)
https://code.djangoproject.com/ticket/30332 - Postgres ordering ARRAY_AGG 
and STRING_AGG do not support expression. (accepted)

*Reviewed/committed:*
https://github.com/django/djangoproject.com/pull/894 - Updated 
robots.docs.txt for Django 2.2.
https://github.com/django/django/pull/11163 - Fixed forms.model_to_dict() 
result if empty list of fields is passed.
https://github.com/django/django/pull/11158 - Fixed #30307 -- Fixed 
incorrect quoting of database user password when using dbshell on Oracle.
https://github.com/django/django/pull/11175 - Fixed bidirectionality on the 
congrats page.
https://github.com/django/django/pull/11172 - Fixed #30332 -- Fixed crash 
of ordering by expressions with params in ArrayAgg and StringAgg.

*Reviewed:*
https://github.com/django/django/pull/11170 - Forced utf-8 encoding when 
loading debug templates.
https://github.com/django/django/pull/11155 - Fixed #30304 -- Added support 
for the HttpOnly, SameSite, and Secure flags on language cookies.
https://github.com/django/django/pull/11138 - Fixed #28373 -- Used 
connection timezone instead of UTC when making dates timezone-aware on 
MySQL, SQLite, and Oracle.
https://github.com/django/django/pull/11095 - Added 
ModelAdmin.get_inlines() hook.

*Authored:*
https://github.com/django/django/pull/11154 - Fixed #30259 -- Fixed crash 
of admin views when properties don't have admin_order_field attribute.
https://github.com/django/django/pull/11161 - Made minor fixes in the "How 
is Django Formed?" documentation.
https://github.com/django/django/pull/11171 - Fixed #30331 -- Added support 
for Psycopg 2.8+.
https://github.com/django/django/pull/11174 - [2.1.x] Refs #30331 -- Doc'd 
that psycopg2 < 2.8 is required.

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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/cfe75851-dd59-45e8-990a-1678cc7aae31%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC Proposal (FormSet Improvement)

[PARTH PATIL]

I have done some MAJOR changes/improvements to my proposal please have a 
look. I have added technical description and addressed more issues related 
to the forrmsets. Suggest any changes if needed.



On Saturday, April 6, 2019 at 10:38:42 PM UTC+5:30, Asif Saif Uddin wrote:
>
> I will try to come up with an initial step for that hopefully by tomorrow. 
> In the meantime, I hope you will keep trying to improve your proposal by 
> analyzing open form/formset related issues, some of whom you could try to 
> fix to get more insight.
>
> On Saturday, April 6, 2019 at 10:30:02 PM UTC+6, PARTH PATIL wrote:
>>
>> Sure that would be nice, as I even mentioned in my abstract I definitely 
>> need help for that one.
>>
>> On Saturday, April 6, 2019 at 8:59:01 PM UTC+5:30, Asif Saif Uddin wrote:
>>>
>>> Regarding the declarative syntax, I might share some insights later with 
>>> you.
>>>
>>> On Tuesday, April 2, 2019 at 1:29:33 AM UTC+6, PARTH PATIL wrote:

 Here is a link to my GSoC proposal
 Its a first draft so you are open to comment and suggest changes


 https://docs.google.com/document/d/1JuoVOU5xMwXY7JrHJshezIyuIpFfoEM49rO3e0rfNhE/edit?usp=sharing


 Best Regards,

 PARTH PATIL

 SOFTWARE DEVELOPER, AUV-IITB

 CONVENOR, ELECTRONICS & ROBOTICS CLUB IIT BOMBAY.

 [image: Image result for FACEBOOK ROUND ICON] 
  [image: Image result for 
 instagram ROUND ICON]  [image: 
 Image result for linkedin ROUND ICON] 
 



-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8b9f7237-db7a-4bcb-949a-03197382eeb0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Help for GSoC proposal (Formset improvements)

[PARTH PATIL]

I came across this ticket while going over the feature list of Forms and 
Formsets (# 18830 )

Feature requested in this thicket is something like

*FormWizard:*
* It will be like a container which can have forms, formsets, and 
formwizards itself.*




On Tuesday, March 26, 2019 at 11:26:56 PM UTC+5:30, PARTH PATIL wrote:
>
> I was planning  to do the "Formset Improvements 
> " 
> project in GSoC. I would need some more explanation on what is expected as 
> nothing was clearly mentioned there.
> You can link the related tickets or elaborate on what is needed that would 
> be helpful.
>
> I dug a little bit deeper into this. and found some related issues 1 
> 
>  
> | 2. 
> 
>
> I'm planning to add a request variable in the BaseFormSet Class 
> 
>  
> and then handle it such that it will be available within every form (not 
> completely polished till now).
>
>1. Is this a good approach?
>2. Will this solve the problem? (If not please mention the problems 
>which will not be solved
>
> I am also looking for some additional features that maybe added to formset 
> so am open for suggestions.
> I'm currently in middle of making the abstract so before moving forward i 
> would like to get some confirmation that this is correct approach. Thank you
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b5ed1b63-84f7-4acc-8633-6c72336f2f82%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Help for GSoC proposal (Formset improvements)

[PARTH PATIL]

(Sorry I typed the incomplete message in the last post)

I came across this ticket while going over the feature list of Forms and 
Formsets (# 18830 )

Feature requested in this thicket is something like

*FormWizard:*
* It will be like a container which can have forms, formsets, and 
formwizards itself.*
 

   1. Is this kind of feature still required?
   2. Will this be a good addition to the Form?
   3. Should I mention this in my proposal, as there is few time left for 
   the final submission I may not be able to draft it properly?

The possible use of this will be to attach different forms in an HTML and 
this form wizard will handle saving, etc of the forms. I was thinking of 
keeping something like a management form similar to formset which will 
handle the individual object and ensure which fields correspond to which 
form/formset element within the wizard.



On Tuesday, March 26, 2019 at 11:26:56 PM UTC+5:30, PARTH PATIL wrote:
>
> I was planning  to do the "Formset Improvements 
> " 
> project in GSoC. I would need some more explanation on what is expected as 
> nothing was clearly mentioned there.
> You can link the related tickets or elaborate on what is needed that would 
> be helpful.
>
> I dug a little bit deeper into this. and found some related issues 1 
> 
>  
> | 2. 
> 
>
> I'm planning to add a request variable in the BaseFormSet Class 
> 
>  
> and then handle it such that it will be available within every form (not 
> completely polished till now).
>
>1. Is this a good approach?
>2. Will this solve the problem? (If not please mention the problems 
>which will not be solved
>
> I am also looking for some additional features that maybe added to formset 
> so am open for suggestions.
> I'm currently in middle of making the abstract so before moving forward i 
> would like to get some confirmation that this is correct approach. Thank you
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0e6fe881-ea44-41b4-99e5-190841e66e20%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Help for GSoC proposal (Formset improvements)

[Carlton Gibson]

Hi Parth. 

Well, the wizard (&co) got moved out to it's own 
app https://django-formtools.readthedocs.io/en/latest/
But yes, there's no reason why this sort of thing wouldn't potentially in 
scope. 

Kind Regards,

Carlton


On Sunday, 7 April 2019 23:47:23 UTC+2, PARTH PATIL wrote:
>
> (Sorry I typed the incomplete message in the last post)
>
> I came across this ticket while going over the feature list of Forms and 
> Formsets (# 18830 )
>
> Feature requested in this thicket is something like
>
> *FormWizard:*
> * It will be like a container which can have forms, formsets, and 
> formwizards itself.*
>  
>
>1. Is this kind of feature still required?
>2. Will this be a good addition to the Form?
>3. Should I mention this in my proposal, as there is few time left for 
>the final submission I may not be able to draft it properly?
>
> The possible use of this will be to attach different forms in an HTML and 
> this form wizard will handle saving, etc of the forms. I was thinking of 
> keeping something like a management form similar to formset which will 
> handle the individual object and ensure which fields correspond to which 
> form/formset element within the wizard.
>
>
>
> On Tuesday, March 26, 2019 at 11:26:56 PM UTC+5:30, PARTH PATIL wrote:
>>
>> I was planning  to do the "Formset Improvements 
>> " 
>> project in GSoC. I would need some more explanation on what is expected as 
>> nothing was clearly mentioned there.
>> You can link the related tickets or elaborate on what is needed that 
>> would be helpful.
>>
>> I dug a little bit deeper into this. and found some related issues 1 
>> 
>>  
>> | 2. 
>> 
>>
>> I'm planning to add a request variable in the BaseFormSet Class 
>> 
>>  
>> and then handle it such that it will be available within every form (not 
>> completely polished till now).
>>
>>1. Is this a good approach?
>>2. Will this solve the problem? (If not please mention the problems 
>>which will not be solved
>>
>> I am also looking for some additional features that maybe added to 
>> formset so am open for suggestions.
>> I'm currently in middle of making the abstract so before moving forward i 
>> would like to get some confirmation that this is correct approach. Thank you
>>
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/519108f2-4030-49d3-8ce8-137f32a48743%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.