Re: Newer constraint declarations and Foreign Keys

[charettes]

If you're interested in following the development of the database level 
foreign key constraints feature you should CC to #21961 [0]

The latest attempt at implementing them was recently closed due to 
inactivity [1]

Cheers,
Simon

[0] https://code.djangoproject.com/ticket/21961
[1] https://github.com/django/django/pull/14550

Le lundi 7 mars 2022 à 14:32:20 UTC-5, Adam Johnson a écrit :

> No, there is not currently a way in Django to declare such constraints. 
> You can always create them in a migration using the RawSQL operation, then 
> rely on them in your code.
>
> This blog post relates to custom relationships which would allow you to 
> model them, I think: 
> https://schinckel.net/2021/07/14/django-implied-relationship/
>
>
> On Mon, Mar 7, 2022 at 5:43 PM dans...@gmail.com  
> wrote:
>
>> Hi guys,
>>
>> I remember that there is a new way to declare constraints in class Meta 
>> on a model, and that this is preferable for unique_together constraints.
>>
>> I've long wanted a way with Django to have database foreign key 
>> constraints cascade in the database rather than via Django.   Is there now 
>> a way to do 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-develop...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/3e28c4b0-896d-49fa-b768-a30c3db96c23n%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/11546e34-ffa1-4327-82a9-2b8e32d15ef2n%40googlegroups.com.

Re: GSOC 22

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

Yes - there's a wiki page here with lots of info:
https://code.djangoproject.com/wiki/SummerOfCode2022

On Mon, Mar 7, 2022 at 12:31 PM Sarthak Kinge 
wrote:

> Is django again participating in GSOC 22?
>
> --
> 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/9055f8c0-6bdb-40c4-b8d5-7610ff6b370bn%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/CAMyDDM2uft50ejNVSt1Ur80TLQt25Cmuo%3Dpt8ksEMKiDR%3DC1VQ%40mail.gmail.com.

Re: Newer constraint declarations and Foreign Keys

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

No, there is not currently a way in Django to declare such constraints. You
can always create them in a migration using the RawSQL operation, then rely
on them in your code.

This blog post relates to custom relationships which would allow you to
model them, I think:
https://schinckel.net/2021/07/14/django-implied-relationship/


On Mon, Mar 7, 2022 at 5:43 PM dans...@gmail.com  wrote:

> Hi guys,
>
> I remember that there is a new way to declare constraints in class Meta on
> a model, and that this is preferable for unique_together constraints.
>
> I've long wanted a way with Django to have database foreign key
> constraints cascade in the database rather than via Django.   Is there now
> a way to do 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/3e28c4b0-896d-49fa-b768-a30c3db96c23n%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/CAMyDDM3eDEX%2B4GbLco0zU%3D5SFmfLMXgNBOqQC-N6Nj%3Dk3CtK-A%40mail.gmail.com.

Newer constraint declarations and Foreign Keys

[dans...@gmail.com]

Hi guys,

I remember that there is a new way to declare constraints in class Meta on 
a model, and that this is preferable for unique_together constraints.

I've long wanted a way with Django to have database foreign key constraints 
cascade in the database rather than via Django.   Is there now a way to do 
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/3e28c4b0-896d-49fa-b768-a30c3db96c23n%40googlegroups.com.

GSOC 22

[Sarthak Kinge]

Is django again participating in GSOC 22?

-- 
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/9055f8c0-6bdb-40c4-b8d5-7610ff6b370bn%40googlegroups.com.

Re: Is_ajax replacement??

[Jet Ezra]

Thanks, I think I will always add small module when needed


On Thursday, February 24, 2022 at 11:33:30 AM UTC+3 Adam Johnson wrote:

> The feature was deprecated in Django 3.1 - the release note covers 
> alternatives: https://docs.djangoproject.com/en/3.1/releases/3.1/#id2
>
> If you didn't detect this until Django 4.0 I would recommend reading the 
> documentation on deprecation warnings so you can discover deprecations when 
> they happen: 
> https://docs.djangoproject.com/en/4.0/howto/upgrade-version/#resolving-deprecation-warnings
>
> On Thu, Feb 24, 2022 at 6:49 AM Jet Ezra  wrote:
>
>> Hello team?
>>
>> So how are we checking for ajax-based in django 4+ if is_ajax() was 
>> deprecated??
>>
>> -- 
>> jet
>>
>> -- 
>> 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/CAMjc0xVkfsJm90tD8Q4%2B5KpyD4Z2FFeXAntc3K08M8EYg3hyQw%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/b485d334-4c7e-4e3a-8a34-d95539d66a35n%40googlegroups.com.

Re: RFC #33561 -- Synchronize user attributes on every authentication with RemoteUserBackend

[Adrian Torres Justo]

Alright, I'm still not 100% convinced it wouldn't be best having them as 
separate methods, but for the sake of moving things along I'll implement it.

One thing that's not quite clear: you mentioned adding a backwards 
compatibility warning, is this the same as a RemovedInDjangoXXWarning? 
Should I follow the documentation at [1] for this implementation?

[1] 
https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/#deprecating-a-feature

Cheers,
Adrian

On Saturday, March 5, 2022 at 7:30:18 PM UTC+1 f.apo...@gmail.com wrote:

> Hi Adrian,
>
> On Saturday, March 5, 2022 at 5:13:14 PM UTC+1 ator...@redhat.com wrote:
>
>> - Existing RemoteUserBackend implementations won't need to change 
>> signatures whenever backwards compatibility is removed
>> - RemoteUserBackend implementations won't need to do anything in order to 
>> support Django versions in which the feature doesn't exist (e.g. 3.9) and 
>> versions in which the feature exists and is not backwards-compatible (e.g. 
>> 5.1)
>>
>
> While this is true, the "migration" path for implementors is simply to 
> change the function to something like:
>
> ```
> def configure_user(self, request, user, created=False):
> if not created: return
>… do whatever you already did 
> ```
>
> and it will stay compatible with current behavior and the new behavior.
>  
>
>> - The code footprint within Django, not counting documentation and tests, 
>> is like 3 LOC
>>
>
> I do understand that, but I don't think it is as simple as that. With the 
> separated methods (unless we pass created to synchronize_user as well) 
> you'd do synchronization always even when the user was just created even 
> though configure_user could take care of that in one go.
>
> - Anyone who wants to extend a RemoteUserBackend implementation can easily 
>> and cleanly extend/replace the synchronization and initial setup 
>> independently of each other, if everything is done in the same method this 
>> can get messy
>>
>
> I do not really think this will be the case since those methods are empty 
> by default… Those backends are so simple that at some point one can simply 
> write their own if subclassing might become to much of a hazzle.
>  
>
>> def configure_user(self, request, user, created):
>> if created:
>> user = self.initial_configuration(request, user)
>> user = self.synchronize(request, user)
>> return user
>>
>> Which is the same as having two separate methods for initial 
>> configuration and synchronization, but with extra steps.
>>
>
> I do not think this will be common though. I rather think that usually one 
> would do the same thing on creation and on sync. 
>  
>
>> Have a good weekend
>>
>
> Thanks, you as well!
>
> 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/cbb24085-a610-44ec-a5df-f58e6ab06f0cn%40googlegroups.com.