Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Schema breaks with OneToOneField #4955

Closed
5 of 6 tasks
dbinetti opened this issue Mar 10, 2017 · 3 comments
Closed
5 of 6 tasks

Schema breaks with OneToOneField #4955

dbinetti opened this issue Mar 10, 2017 · 3 comments
Milestone

Comments

@dbinetti
Copy link

dbinetti commented Mar 10, 2017

Checklist

  • I have verified that that issue exists against the master branch of Django REST framework.
  • I have searched for similar issues in both open and closed tickets and cannot find a duplicate.
  • This is not a usage question. (Those should be directed to the discussion group instead.)
  • This cannot be dealt with as a third party library. (We prefer new functionality to be in the form of third party libraries where possible.)
  • I have reduced the issue to the simplest possible case.
  • I have included a failing test as a pull request. (If you are unable to do so we can still accept the issue.)

Steps to reproduce

With:

# models.py
class Alpha(models.Model):
    id = models.UUIDField(
        primary_key=True,
        default=uuid.uuid4,
        editable=False,
    )

    public_name = models.CharField(
        max_length=255,
    )


class AlphaPrivate(models.Model):
    alpha = models.OneToOneField(
        'Alpha',
        on_delete=models.CASCADE,
        primary_key=True,
        parent_link=True,
    )

    private_name = models.CharField(
        max_length=255,
    )

Attempt to render a schema with normal schema_view

Expected behavior

Renders schema.

Actual behavior

Raises UnboundLocalError

Investigation

The most direct cause of the error is that there is a Try/Except block at L531 of schemas.py that tries to get a field from the model that doesn't exist. This throws an Exception, but there is a pass in the except block which just allows things to keep going, producing the error when the next line of code attempts to access the uninstantiated variable. (Sorry for the "duh" explanation, but it is odd that there would be a pass there -- perhaps some debugging code that wasn't removed?)

Anyway, the model._meta.get_field(variable) at L532 fails because the variable being checked (which is returned by uritemplate.variables()) is 'id' and there is no field named 'id' in this model; the field being used as the actual id is 'alpha', which is a OneToOneField set as a primary key and parent link.

I'm using AlphaPrivate to maintain some private information with different permissions that would otherwise be part of Alpha -- hence the primary_key=True and parent_link=True in the above. Now I should mention that I'm unsure if I'm misconfiguring things in some way by using the above approach. That's why I haven't supplied a test: it seems just as likely that I am not doing things in the right way as I've found a legit bug.

Happy to expand further if necessary.

@dbinetti
Copy link
Author

dbinetti commented Mar 10, 2017

Oh, and I forgot to mention that this is only happening as of DRF 3.6. Everything worked as expected on 3.5.

@paultiplady
Copy link

paultiplady commented Mar 10, 2017

I've hit this too, and at least with my code path, the issue is actually that the field model_field is not initialized; initializing it correctly at line 530 of schemas.py like so resolves the problem:

                model_field = None  # <== Add this
                # Attempt to infer a field description if possible.
                try:
                    model_field = model._meta.get_field(variable)
                except:
                    pass

@tomchristie
Copy link
Member

tomchristie commented Mar 10, 2017

Closed via #4956.

@tomchristie tomchristie added this to the 3.6.2 Release milestone Mar 10, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants