GSoC Advice Needed

[Divya Soni]

Dear Guardians of the Django Universe,

My name is Divya Soni, and I'm second year CSE Undergrad from India. I want 
to participate in GSoC 2021, and have been looking at The Django Foundation 
as one of my possible options. I need your advice about my particular 
situation.

I'm well versed in Object Oriented Programming in C++ and have used Python 
before. I have also been working with HTML, CSS, Javascript and React for a 
while. However, I have not used Django very much. It is something that I've 
always wanted to learn, but never got the chance to. So I was thinking that 
in the almost 4 months that I have before the proposal deadline next year, 
I could dive into Django and become proficient enough so that I can 
contribute to the project.

However, I have no way to gauge how plausible such an idea is.  So rather 
than spending time trying to figure it out by hit and trial, I thought it'd 
be a lot better to ask someone who'd know about it the best - you guys! 
Hence, my email.

Please let me know what your thought are on my idea. Would I be able to 
gain enough proficiency in the time frame that I have? Or is it a bit too 
optimistic?

Also, thank you for the amazing work that all of you do here!

Divya Soni  


-- 
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/f8a475a3-92f8-49af-8fca-e23b0943d00cn%40googlegroups.com.

Re: Django deployments

[Ing.Daniel Bojorge]

I you use wamp, you have apache, so just must set other site in your
setting of apache.


Dios L@s Bendiga

Saludos,



[image: --]

daniel.bojorge
[image: http://]about.me/daniel.bojorge

 [image: snake]*Curso Desarrollo Web con Python usando Django 2.2 Para
Principiantes con Descuento 95%    *[image:
snake]
*WebService RestFul API con Python usando Django RestFrameWork*

*Fácil Replicación de Cualquier Base de Datos y/o Sistema Operativo*

*Programación en Capas (Web y Escritorio)* 
Mi Blog 
Nicaragua

"Si ustedes permanecen unidos a mí, y si permanecen fieles a mis
enseñanzas, pidan lo que quieran y se les dará.
(Juan 15:7 DHH)
Bendito el varón que se fía en el SEÑOR, y cuya confianza es el SEÑOR.
(Jeremías 17:7 RV2000)




El mié, 17 nov 2021 a las 14:35, Elango Venkat ()
escribió:

> Hi all, can anyone help me on the below or suggestions pls.
>  I need to deploy two django projects in my local server.. one project I
> have deployed with wamp & mod wsgi port 8060
>
> Any way to add config to have other project in port 80
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/CAKqFZP59XtT_WXuKKvgz7RRfT9Cdt96%2Bip_ge9mS2%3D_ZWMwx7w%40mail.gmail.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/CAMQeQjaHP06Y_zO-O6Lku140PbqzXZYAQLyGnu%3DC_eGOLD54hw%40mail.gmail.com.

select_for_update and transactions (bad dev UX in a feature)

[Klemen Štrajhar]

Hi!
I noticed dangerous behaviour with testing and usage of *select_for_update *in 
transactions.
This "feature" crashed some parts of production in our company.
The "feature" I am talking about, is that test runner wraps all tests in a 
transaction. If you use *select_for_update* you have to wrap it in a 
transaction.atomic(). That is quite obvious as django raises an error if 
query is not in a transaction.
This is what happened at our company:

   1. One code block was wrapped in transaction atomic where 
   select_for_update was used. The code was tested in a django test.
   2. transaction.atomic context manager was accidentally removed. The test 
   still passed as test runner wraps test in it's own transaction.
   3. Code was happily deployed
   4. On production server there was no more transaction wrapper and 
   exception was raised at select_for_update
   5. ...
   6. Hotfix galore

Is there any option to separate the transaction wrapper for testing and 
normal code execution? I am not familiar with internals of test runner 
etc., but would gladly take a look.
What are your opinions about this?
- Klemen

-- 
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/be5bd163-5915-4890-b225-78094c773eb8n%40googlegroups.com.

Re: select_for_update and transactions (bad dev UX in a feature)

['Adam Johnson' via Django developers (Contributions to Django itself)]

Hi Klemen

We recently changed atomic() to mark when it is created by the test runner
for this ticket: https://code.djangoproject.com/ticket/33161 . This was for
special case logic around the 'durable' flag to atomic().

Perhaps the newly added tracking can also be used for the check in
select_for_update(), and perhaps other things that require an atomic()
(i.e. they check connection.in_atomic_block). You could investigate if a
patch is feasible.

FWIW I always recommend enabling ATOMIC_REQUESTS and ensuring transactions
are used by default in other code paths such as background tasks.

Thanks,

Adam

On Wed, 17 Nov 2021 at 21:02, Klemen Štrajhar 
wrote:

> Hi!
> I noticed dangerous behaviour with testing and usage of *select_for_update
> *in transactions.
> This "feature" crashed some parts of production in our company.
> The "feature" I am talking about, is that test runner wraps all tests in a
> transaction. If you use *select_for_update* you have to wrap it in a
> transaction.atomic(). That is quite obvious as django raises an error if
> query is not in a transaction.
> This is what happened at our company:
>
>1. One code block was wrapped in transaction atomic where
>select_for_update was used. The code was tested in a django test.
>2. transaction.atomic context manager was accidentally removed. The
>test still passed as test runner wraps test in it's own transaction.
>3. Code was happily deployed
>4. On production server there was no more transaction wrapper and
>exception was raised at select_for_update
>5. ...
>6. Hotfix galore
>
> Is there any option to separate the transaction wrapper for testing and
> normal code execution? I am not familiar with internals of test runner
> etc., but would gladly take a look.
> What are your opinions about this?
> - Klemen
>
> --
> 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/be5bd163-5915-4890-b225-78094c773eb8n%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/CAMyDDM31-kaB6CZVZ2Hk-0A62wAF7-95ifEKYnY%2BDXY4DfkmWw%40mail.gmail.com.

Re: select_for_update and transactions (bad dev UX in a feature)

[Klemen Štrajhar]

Hi Adam

I will check into it.

IMO using ATOMIC_REQUESTS is an antipattern. Views shouldn't know anything 
about the database. Services should handle all persistence related stuff 
and that's why transactions should only be used when necessary.

Best!
Klemen

sreda, 17. november 2021 ob 23:09:58 UTC+1 je oseba Adam Johnson napisala:

> Hi Klemen
>
> We recently changed atomic() to mark when it is created by the test runner 
> for this ticket: https://code.djangoproject.com/ticket/33161 . This was 
> for special case logic around the 'durable' flag to atomic().
>
> Perhaps the newly added tracking can also be used for the check in 
> select_for_update(), and perhaps other things that require an atomic() 
> (i.e. they check connection.in_atomic_block). You could investigate if a 
> patch is feasible.
>
> FWIW I always recommend enabling ATOMIC_REQUESTS and ensuring transactions 
> are used by default in other code paths such as background tasks.
>
> Thanks,
>
> Adam
>
> On Wed, 17 Nov 2021 at 21:02, Klemen Štrajhar  
> wrote:
>
>> Hi!
>> I noticed dangerous behaviour with testing and usage of *select_for_update 
>> *in transactions.
>> This "feature" crashed some parts of production in our company.
>> The "feature" I am talking about, is that test runner wraps all tests in 
>> a transaction. If you use *select_for_update* you have to wrap it in a 
>> transaction.atomic(). That is quite obvious as django raises an error if 
>> query is not in a transaction.
>> This is what happened at our company:
>>
>>1. One code block was wrapped in transaction atomic where 
>>select_for_update was used. The code was tested in a django test.
>>2. transaction.atomic context manager was accidentally removed. The 
>>test still passed as test runner wraps test in it's own transaction.
>>3. Code was happily deployed
>>4. On production server there was no more transaction wrapper and 
>>exception was raised at select_for_update
>>5. ...
>>6. Hotfix galore
>>
>> Is there any option to separate the transaction wrapper for testing and 
>> normal code execution? I am not familiar with internals of test runner 
>> etc., but would gladly take a look.
>> What are your opinions about this?
>> - Klemen
>>
>> -- 
>> 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-develop...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/be5bd163-5915-4890-b225-78094c773eb8n%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/db53c546-65ec-4b2a-b1c3-9fac4e3f041cn%40googlegroups.com.