Opened 10 years ago

Closed 18 months ago

#2843 closed New feature (wontfix)

serializer can't resolve a one-to-many relation from the "foreign" side

Reported by: nikl@… Owned by: nobody
Component: Core (Serialization) Version:
Severity: Normal Keywords: serialize json python xml foreign key one to many relationship
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: yes
Needs tests: yes Patch needs improvement: yes
Easy pickings: no UI/UX: no

Description

best illustrated with a short example:

class Reporter(models.Model):
    name = models.CharField(maxlength=25)

class Article(models.Model):
    reporter = models.ForeignKey(Reporter)

what I want to be able to get is something like the following (python-serialization):

[{'fields': {'articles': [1, 2, 3],
             'name': 'Me'},
  'model': 'news.reporter',
  'pk': '1'}]

currently, if I want to get the information in this format, I have two options:

  • construct a Model-like structure, so it can be used with the serializers
  • turn the one-to-many into a many-to-many relationship

both of these are obviously not a clean solution...

therefore I'd propose to add an extra parameter to export the ids of those related-objects optionally.

if time allows and there are no objections to this, I'll try to throw together a patch this weekend.

Attachments (5)

svn.diff (3.4 KB) - added by "Nikolaus Schlemm" <nikl@…> 10 years ago.
no time on the weekend, but now it's done :) one small change to what I previously wrote: using "article_set" instead of "articles" seemed much more consistent with the rest of the django api
svn.2.diff (3.7 KB) - added by "Nikolaus Schlemm" <nikl@…> 10 years ago.
now with the paths relative to django root-dir, not the serializers dir
include_reverse_relations.diff (2.9 KB) - added by Nikolaus Schlemm <nikl@…> 10 years ago.
just a quick option rename. unfortunately, I don't much more time right as I'm in the middle of starting a new job - plus moving from one city to another…
include_reverse_relations.2.diff (3.8 KB) - added by Nikolaus Schlemm <nikl@…> 10 years ago.
argh! forgot django/core/serializers/python.py in the last diff…
include_reverse_relations.3.diff (3.7 KB) - added by supervacuo 5 years ago.
I see that there is now a GSOC proposal including this functionality, but that plan involves a completely new serialization interface. 5 years later, Nikolaus's patch applies to trunk with only minimal changes (attached) -- is there any chance that, once it has tests and documentation, this approach could make it into trunk if / in case the GSOC idea doesn't work out?

Download all attachments as: .zip

Change History (15)

Changed 10 years ago by "Nikolaus Schlemm" <nikl@…>

Attachment: svn.diff added

no time on the weekend, but now it's done :)

one small change to what I previously wrote: using "article_set" instead of "articles" seemed much more consistent with the rest of the django api

comment:1 Changed 10 years ago by "Nikolaus Schlemm" <nikl@…>

Summary: serializer can't resolve a one-to-many relation from the "foreign" side[patch] serializer can't resolve a one-to-many relation from the "foreign" side

Changed 10 years ago by "Nikolaus Schlemm" <nikl@…>

Attachment: svn.2.diff added

now with the paths relative to django root-dir, not the serializers dir

comment:2 Changed 10 years ago by Nikolaus Schlemm <nikl@…>

Severity: majornormal
Type: defectenhancement

comment:3 Changed 10 years ago by (none)

milestone: Version 1.0

Milestone Version 1.0 deleted

comment:4 Changed 10 years ago by Jacob

Needs documentation: set
Needs tests: set
Patch needs improvement: set
Triage Stage: UnreviewedAccepted

This looks good to me, but needs a few changes:

  • I'd like the option "export_o2m" to be changed to something more clear. How about "include_reverse_relations"?
  • Tests need to be written for the new behavior.
  • As does documentation, but since the serializers doc is not where close to finished and that's my fault, I'll check this in without docs if someone else can handle the first two items.

Changed 10 years ago by Nikolaus Schlemm <nikl@…>

just a quick option rename. unfortunately, I don't much more time right as I'm in the middle of starting a new job - plus moving from one city to another...

Changed 10 years ago by Nikolaus Schlemm <nikl@…>

argh! forgot django/core/serializers/python.py in the last diff...

comment:5 Changed 6 years ago by Łukasz Rekucki

Severity: normalNormal
Type: enhancementNew feature

comment:6 Changed 5 years ago by Aymeric Augustin

UI/UX: unset

Change UI/UX from NULL to False.

comment:7 Changed 5 years ago by Aymeric Augustin

Easy pickings: unset

Change Easy pickings from NULL to False.

Changed 5 years ago by supervacuo

I see that there is now a GSOC proposal including this functionality, but that plan involves a completely new serialization interface. 5 years later, Nikolaus's patch applies to trunk with only minimal changes (attached) -- is there any chance that, once it has tests and documentation, this approach could make it into trunk if / in case the GSOC idea doesn't work out?

comment:8 Changed 4 years ago by Aymeric Augustin

Component: Core (Other)Core (Serialization)

comment:9 Changed 2 years ago by Tim Graham

Summary: [patch] serializer can't resolve a one-to-many relation from the "foreign" sideserializer can't resolve a one-to-many relation from the "foreign" side

comment:10 Changed 18 months ago by Russell Keith-Magee

Resolution: wontfix
Status: newclosed

I'm going to make an executive decision and close this as a wontfix.

This specific ticket is asking for a piecemeal addition to Django's serializers; the real underlying problem is that Django's serializers aren't as flexible as they need to be for real world problems. The example given in this ticket is one type of serialisation for which there are real use cases, but there are many others (e.g, depth > 1 serialization of relationships).

Once upon a time, I harboured dreams of writing a fully flexible serialisation framework for Django; luckily, that is no longer required, as Tom Christie has written a very robust and flexible set of serializers for Django REST Framework. If we want this in Django, we should maybe approach Tom to pull that piece of REST Framework into Django; but frankly, I'm not convinced this is worth the code churn (and it's one more thing that the core team doesn't have to worry about, which is a good thing).

Note: See TracTickets for help on using tickets.
Back to Top