Coercing ManyRelatedManager to string raises StopIteration exception

[rasca]

As with #22982 this is broken in 1.7.

It should be trivial to workaround adding

    def __str__(self):
        return repr(self)

as in 29585e9b6a0ce15dc0149c8424cd11c3e27ee295 but this may be present in some other parts of django or custom managers, so maybe it would be a good idea to try a better fix.

[Gabriel Muñumel]

Here is the PR: ​https://github.com/django/django/pull/4191

I got an error with the isort test. I don't know if it is related to my change.

[Simon Charette]

You should base your patch against the master branch. It will be backported by the committer.

[Gabriel Muñumel]

Replying to charettes:

You should base your patch against the master branch. It will be backported by the committer.

But is this apply for any change? For instance, if I have a change for 1.4 branch I need to go against master branch?

[Gabriel Muñumel]

I saw this documentation: ​https://docs.djangoproject.com/en/1.7/internals/contributing/committing-code/#committing-guidelines . If I want to backport my PR I need to change its title? The revision hash code is the code of the commit?

[Simon Charette]

For instance, if I have a change for 1.4 branch I need to go against master branch?

Yes, but per our ​backport policy the stable/1.4.x would only receive security fixes and bug fixes for data loss issues.

I saw this documentation: ​​https://docs.djangoproject.com/en/1.7/internals/contributing/committing-code/#committing-guidelines . If I want to backport my PR I need to change its title? The revision hash code is the code of the commit?

The commit message will be changed by the committer through an automated script.

You just have a to open a new pull request against master with your changes and a commit message following ​the guidelines.

e.g Fixed #24352 -- Prevented ManyRelatedManager from raising an exception when converted to string.

[Gabriel Muñumel]

In my PR against master I see that alot files have been changed, this is because I'm comparing 1.7 branch against master. Is this normal? I guess not. I tried several ways to just make a PR against master with just my change but I cannot do it. Thanks a lot for the help.

[Tim Graham]

You need to branch off of master, apply your patch, then create a pull request with that branch.

[Gabriel Muñumel]

Replying to timgraham:

You need to branch off of master, apply your patch, then create a pull request with that branch.

Thanks for the help. But still don't get it. Is there a documentation about this? First how I create a branch off of master?. I just did

git checkout -b ticket_24352_1_7 master

Is that correct?
If I made the change in that repository the test will fail because the change is for 1.7 branch.

I'm a bit frustated with this :(

[Tim Graham]

I think you're on the right track. How does the test fail? Is the bug not present on master?

​Working with Git/GitHub docs.

[Gabriel Muñumel]

Yes, I think the bug is 1.7 specific. I try running this test in m2m_regress on master branch.

def test_many_related_manager_str(self):
        c1 = TagCollection.objects.create(name='c1')
        self.assertIn('ManyRelatedManager', str(c1.tags))

But always get an error related to:

Traceback (most recent call last):
  File "/home/alucard/workspace/Code/django/tests/m2m_regress/tests.py", line 117, in test_many_related_manager_str
    self.assertIn('ManyRelatedManager', str(c1.tags))
AssertionError: u'ManyRelatedManager' not found in 'm2m_regress.Tag.None'

[Gabriel Muñumel]

New PR: ​https://github.com/django/django/commit/798ed6f8aab97841d89e4659dbe74c9d35089b79

Let me know if it's ok.

[Tim Graham <timograham@…>]

In 0831a43c3afc3f93b8ed0c58630836e38248be12:

[1.7.x] Fixed #24352 -- Fixed crash when coercing ManyRelatedManager to a string.