Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Updating a resource with a full ToManyField representation fails #307

joshbohde opened this Issue · 17 comments

8 participants


As reported in #tastypie by @jpadilla, when sending a PUT to a resource with a ToManyField, the Django ORM aborts with the message int() argument must be a string or a number, not 'ManyRelatedManager'.

Reference resources are located in this gist:
A traceback is located here:
The kwargs that are causing the issue are here:

The problem was found when piping the result of a get_detail on the BookingResource into a put_detail.



I got this message:

int() argument must be a string or a number, not 'list'

as well as

int() argument must be a string or a number, not 'ManyRelatedManager'

during a PUT to a resource with a ToManyField.

Traceback according the 'list':

@joshbohde joshbohde referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.

Im also getting this message when attempting to POST a "3-layer" full=true nested resource, that has the relations filled up.

int() argument must be a string or a number, not 'list'

This is a major bug

@joshbohde joshbohde referenced this issue from a commit in joshbohde/django-tastypie
@joshbohde joshbohde Failing test for #307
Let's say we have 3 resources, A, B, and C, where A has a ToMany to B and B has a ToMany to C.

When creating or updating on A where the list of Bs is full (not a list of resource_uris), the list of Cs is passed to the ORM as a filter, which triggers a TypeError.

We seem to have multi-level nested working using the 9.12 Perm branch, plus a couple changes:

  1. Your first suggested fix: "Catch the type error, and proceed to pk lookup."
  2. Commenting out line 2082 of
    • This line seems to override the value for related_bundle which is being set in the for loop and thus causing the wrong object to be returned. It seemed like we kept getting the parent and not the child in the nest.

With these two changes our nested->nested->nested resource/posts are working.


I'm pretty sure I'm being an idiot, but where can I find the 9.11 branch?


The latest revision of this repository still doesn't save related resources (the installed egg is listed as 9.11).

POST fails to save anything that is 3 or more levels deep in one go. Returns with success, but 3rd level or more has not been saved.



You are correct: 9.11 (the latest stable release) does not support nested posts/saves. Nested saving was added in the Perms Branch (I think it comes down as 9.12.beta??). However, when we initially tested this version (9.12.beta...) it did not seem to work and also seemed to break 1-2 level deep nested saves that previously did work in 9.11 (stable). See issue #410 for more details on this.

My post from a few days back has a work-around solution using the 9.12.beta branch with some changes that seems to be saving 1, 2, 3, 4, etc. - level nested branches.

Hope this helps clarify. Let me know if you get it work and get any successful tests.


Thanks for the clarification @btste.

My only remaining issue now is that there is no existing branch which implements both deep nested saving and correct related resource validation as fixed in c5451b9.

It seems that development is continuing separately on the master and perm branch meaning we have some features we need on the master branch and some on perms.


Has anyone got nested to pass tests based on @btste 's comments? @toastdriven ?


@desimone I didn't look into @bste's quick-fix as I know what needs to change in Tastypie to fix it. I'm still working on it and got some more progress done on the perms branch the other night.


I'll stay tuned, and monitor the perms branch. Thanks @toastdriven , @btste


Thanks @toastdriven, keep us posted.


This is also a blocker for me, hitting the:
TypeError: int() argument must be a string or a number, not 'RelatedManager'

when I PUT with a double nested resource - it seems to go well for the first nesting, but in the second nesting a RelatedManager object appears in the field value that gets passed to a queryset filter, which I think is used for finding the to-be-updated primary nested resource. The filter logic then tries to cast it to int and the exception is risen.

Thanks for working on this.


@btste could you post the code for your quick fix as a gist or some-such so those of us who need a quick fix can see what you mean? Sorry for being dense. @toastdriven how long how long?


In case it helps. It's been awhile since I played with this - so no guarantees here. I think this is what we did using PERMS ~9.12

Step 1)

  • Made this change:

Step 2)
* comment out line 2082 -

Thanks for the info @btste I'm gonna give it a go!


Fixed as of SHA: d850758

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.