Re: Feature Request: Allow Serialize Foreign Keys as Ids

[Curtis Maloney]

On Sat, 5 Aug 2023, at 06:47, Ryan Gartin wrote:
> You are correct state_id is not a field on the model, state is, and using 
> “state” in the field lists works.
> 
> I would like to propose that if  ‘state_id’ is a valid property on the 
> queryset (and in the database) that is should be serialized.

I think the main limitation you're hitting here is the core serializers in 
Django are really primarily only tuned for generating fixtures; This is why 
pretty much every REST API framework for Django has had its own version of the 
idea.

The built in ones are simply not flexible enough.

IMHO the serializer is the most important part of any REST / API framework.

> While I understand that this is my personal preference I think it is 
> reasonable to request that if QuerySet.state_id returns a valid value then it 
> should also be capable of being serialized as well. 
Way back in the mid 2000s I did my own sub-classes of the core Serializers to 
allow this sort of thing. Since then I've tried maybe half a dozen REST API 
libs (including writing my own), and none of them used core serializers.

That's not to say your idea is without merit. I think if you give it an 
afternoon's digging you could add an option to the django core serializers to 
list non-field attributes to include.

--
Curtis
> 
> On Thursday, August 3, 2023 at 9:46:27 PM UTC-4 Curtis Maloney wrote:
>> __
>> Hi Mike,
>> 
>> On Fri, 4 Aug 2023, at 06:03, Ryan Gartin wrote:
>>> I came across this issue calling the following and FK fields with _id are 
>>> ignored:
>>> serialize('json', , fields=['title', 'state_id']). 
>> 
>> I think the problem you've run into here is "state_id" is not a Field on 
>> your model; it's where the raw PK value for your ForeignKey is stored.
>> 
>> I've just double checked the code for serialize, and I'm pretty sure the 
>> default behavior for a ForeignKey field _is_ _already_ to output the PK 
>> value.
>> 
>> What happens in your code if you put "state" instead of "state_id" in the 
>> field list?
>> 
>> --
>> Curtis

-- 
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/d9e79eb8-aeea-48b1-9837-7e97614e%40app.fastmail.com.

Re: Sync and Async versions of the same function: guidelines for contributors

[Jon Janzen]

Hey there,

> Not that much with a 50 lines function. that could easily become a 
maintenance burden.
> what do you think about code duplication of async function ? (please 
point me to existing threads if the discussion already occurred)

I flagged this problem 
in 
https://forum.djangoproject.com/t/asyncifying-django-contrib-auth-and-signals-and-maybe-sessions/18770
and before that 
in https://groups.google.com/g/django-developers/c/T8zBnYO78YQ

There doesn't really seem to be a good resolution to this problem right 
now, unfortunately :(

> why do we see almost no sync wrapper (async_to_sync) in django's code 
base ? Is that a best practice ?

I can't give an authoritative answer but my intuition is that we are still 
in the early stages of the process of asyncifying everything and we're at 
the second bullet point from DEP-009 ("Sync-native, with an async wrapper") 
and haven't yet gotten started on an async-native implementation with a 
sync wrapper.

There are a few key things missing from core django before that's possible. 
Some of which are laid out in that forum thread I linked above, others are 
listed directly in the DEP like the ORM being fully asyncified (right now 
it's just an async wrapper around sync code) which is somewhat blocked on 
async database implementations (psycopg3 being the first one supported).

I don't really have any answers for you, just some more thoughts. Hope 
that's helpful!

Jon
On Saturday, August 5, 2023 at 10:23:00 AM UTC-7 Olivier Tabone wrote:

> Hi all,
>
> While working on async related tickets (eg #34717, and more recently 
> #34757) I noticed code duplication between sync and async version of same 
> functions:
>
> some examples: (no personal offense ❤️)
>
>
>- acheck_password /  check_password in base_user.py 
>
> 
>- get_many() / a_getmany() in cache/backends/base.py 
>
> 
>
> and of course the way I fixed #34717, now we have some code duplication in 
> aget_object_or_404 
> 
>  
> / aget_list_or_404 
> 
>
> As I'm working on #34757, and following this pattern, there would be some 
> duplication of the TestClient._handle_redirects 
> 
>  
> method to support the async case.
>
> I'm kind of ok when duplicating a 3 lines function. Not that much with a 
> 50 lines function. that could easily become a maintenance burden.
>
> I've read DEP-009  
> a few 
> times and the plan at the time was (quoted from the "Technical Overview")
>
> Each feature will go through three stages of implementation:
>
>- Sync-only (where it is today)
>- Sync-native, with an async wrapper
>- Async-native, with a sync wrapper
>
>
> I was wondering:
> 1- why do we see almost no sync wrapper (async_to_sync) in django's code 
> base ? Is that a best practice ?
> 2- what do you think about code duplication of async function ? (please 
> point me to existing threads if the discussion already occurred) What is Ok 
> / What is not ok ? Is there some cleanup to be done ?
>
>
> Cheers,
>
> - Olivier Tabone
>
>
>
>
>
>

-- 
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/be3a9dba-2702-4fbd-baef-c49587892616n%40googlegroups.com.

Sync and Async versions of the same function: guidelines for contributors

[Olivier Tabone]

Hi all,

While working on async related tickets (eg #34717, and more recently 
#34757) I noticed code duplication between sync and async version of same 
functions:

some examples: (no personal offense ❤️)


   - acheck_password /  check_password in base_user.py 
   

   - get_many() / a_getmany() in cache/backends/base.py 
   


and of course the way I fixed #34717, now we have some code duplication in 
aget_object_or_404 

 
/ aget_list_or_404 


As I'm working on #34757, and following this pattern, there would be some 
duplication of the TestClient._handle_redirects 

 
method to support the async case.

I'm kind of ok when duplicating a 3 lines function. Not that much with a 50 
lines function. that could easily become a maintenance burden.

I've read DEP-009  
a few 
times and the plan at the time was (quoted from the "Technical Overview")

Each feature will go through three stages of implementation:

   - Sync-only (where it is today)
   - Sync-native, with an async wrapper
   - Async-native, with a sync wrapper
   

I was wondering:
1- why do we see almost no sync wrapper (async_to_sync) in django's code 
base ? Is that a best practice ?
2- what do you think about code duplication of async function ? (please 
point me to existing threads if the discussion already occurred) What is Ok 
/ What is not ok ? Is there some cleanup to be done ?


Cheers,

- Olivier Tabone





-- 
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/dfe0f343-9c2a-4d01-9a3f-1b4f7c0d45bfn%40googlegroups.com.

Re: Feature Request: Allow Serialize Foreign Keys as Ids

[Vansh NaiK]

How toh hack account


On Saturday, 5 August 2023 at 02:17:12 UTC+5:30 Ryan Gartin wrote:

> You are correct state_id is not a field on the model, state is, and using “
> state” in the field lists works.
>
> I would like to propose that if  ‘state_id’ is a valid property on the 
> queryset (and in the database) that is should be serialized.
>
> It is my preference that a serialized JSON property (to be consumed in a 
> strongly typed language) is reserved for a specific type. I realize Django 
> will determine that `state: int` is an Int and it needs to do a FK lookup 
> and populate that property with the state model but a strongly typed 
> language does not have that ability to determine between two types nor does 
> it have the ability to requery. So my preference when I consume JSON 
> response into my apps is to reserve state: { title: str, etc...} to an 
> object representing State model and use state_id: int wherever I just 
> need the Integer. 
>
> While I understand that this is my personal preference I think it is 
> reasonable to request that if QuerySet.state_id returns a valid value 
> then it should also be capable of being serialized as well. 
>
> On Thursday, August 3, 2023 at 9:46:27 PM UTC-4 Curtis Maloney wrote:
>
>> Hi Mike,
>>
>> On Fri, 4 Aug 2023, at 06:03, Ryan Gartin wrote:
>>
>> I came across this issue calling the following and FK fields with _id are 
>> ignored:
>> serialize('json', , fields=['title', 'state_id']). 
>>
>>
>> I think the problem you've run into here is "state_id" is not a Field on 
>> your model; it's where the raw PK value for your ForeignKey is stored.
>>
>> I've just double checked the code for serialize, and I'm pretty sure the 
>> default behavior for a ForeignKey field _is_ _already_ to output the PK 
>> value.
>>
>> What happens in your code if you put "state" instead of "state_id" in the 
>> field list?
>>
>> --
>> Curtis
>>
>

-- 
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/f55f844a-c1b5-448b-8530-4c40cb13f405n%40googlegroups.com.