Opened 9 years ago

Closed 3 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@…> 9 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@…> 9 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@…> 9 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@…> 9 years ago.
argh! forgot django/core/serializers/python.py in the last diff…
include_reverse_relations.3.diff (3.7 KB) - added by supervacuo 3 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 9 years ago by "Nikolaus Schlemm" <nikl@…>

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 9 years ago by "Nikolaus Schlemm" <nikl@…>

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

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

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

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

  • Severity changed from major to normal
  • Type changed from defect to enhancement

comment:3 Changed 9 years ago by anonymous

  • milestone Version 1.0 deleted

Milestone Version 1.0 deleted

comment:4 Changed 9 years ago by jacob

  • Needs documentation set
  • Needs tests set
  • Patch needs improvement set
  • Triage Stage changed from Unreviewed to Accepted

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 9 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 9 years ago by Nikolaus Schlemm <nikl@…>

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

comment:5 Changed 4 years ago by lrekucki

  • Severity changed from normal to Normal
  • Type changed from enhancement to New feature

comment:6 Changed 4 years ago by aaugustin

  • UI/UX unset

Change UI/UX from NULL to False.

comment:7 Changed 4 years ago by aaugustin

  • Easy pickings unset

Change Easy pickings from NULL to False.

Changed 3 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 2 years ago by aaugustin

  • Component changed from Core (Other) to Core (Serialization)

comment:9 Changed 9 months ago by timgraham

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

comment:10 Changed 3 months ago by freakboy3742

  • Resolution set to wontfix
  • Status changed from new to closed

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