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

Calling /api/<model>/<id>/<attribute> where <attribute> is not a relation bombs with an unhelpful AttributeError #213

Closed
jcmcken opened this issue May 30, 2013 · 3 comments
Labels

Comments

@jcmcken
Copy link

jcmcken commented May 30, 2013

Curl command that I run:

curl http://localhost:5000/api/v1/data/1/id

...where data is my collection_name, /api/v1 is my url_prefix, and id is just the name of the primary key column.

I get this exception:

AttributeError: 'ColumnProperty' object has no attribute 'uselist'

I don't think this is a proper usage of the API, but the error is not helpful. If it's not a valid endpoint, API should raise a 400-level http code, not a 500.

A different AttributeError is raised (with 500 HTTP code) if you call with an attribute that doesn't even exist for the given model, which also seems to be a bug.

Full traceback for the first issue:

Traceback (most recent call last):
  File "/data/sandbox/apps/myapp/venv/lib/python2.6/site-packages/flask/app.py", line 1701, in __call__
    return self.wsgi_app(environ, start_response)
  File "/data/sandbox/apps/myapp/venv/lib/python2.6/site-packages/flask/app.py", line 1689, in wsgi_app
    response = self.make_response(self.handle_exception(e))
  File "/data/sandbox/apps/myapp/venv/lib/python2.6/site-packages/flask/app.py", line 1687, in wsgi_app
    response = self.full_dispatch_request()
  File "/data/sandbox/apps/myapp/venv/lib/python2.6/site-packages/flask/app.py", line 1360, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/data/sandbox/apps/myapp/venv/lib/python2.6/site-packages/flask/app.py", line 1358, in full_dispatch_request
    rv = self.dispatch_request()
  File "/data/sandbox/apps/myapp/venv/lib/python2.6/site-packages/flask/app.py", line 1344, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "/data/sandbox/apps/myapp/venv/lib/python2.6/site-packages/flask_restless/views.py", line 112, in decorator
    return func(*args, **kw)
  File "/data/sandbox/apps/myapp/venv/lib/python2.6/site-packages/flask/views.py", line 83, in view
    return self.dispatch_request(*args, **kwargs)
  File "/data/sandbox/apps/myapp/venv/lib/python2.6/site-packages/flask/views.py", line 150, in dispatch_request
    return meth(*args, **kwargs)
  File "/data/sandbox/apps/myapp/venv/lib/python2.6/site-packages/flask_restless/views.py", line 935, in get
    if is_like_list(instance, relationname):
  File "/data/sandbox/apps/myapp/venv/lib/python2.6/site-packages/flask_restless/helpers.py", line 228, in is_like_list
    return instance._sa_class_manager[relation].property.uselist
AttributeError: 'ColumnProperty' object has no attribute 'uselist'

My requirements file:

Flask==0.9
Flask-Restless==0.11.0
Flask-SQLAlchemy==0.16
FormEncode==1.2.6
Jinja2==2.7
MarkupSafe==0.18
SQLAlchemy==0.8.1
Werkzeug==0.8.3
python-dateutil==2.1
six==1.3.0
wsgiref==0.1.2
@jfinkels
Copy link
Owner

This is definitely a bug.

There may be a way to fix it, but I think a major overhaul of the part of the code that creates API objects (specifically the code in APIManager.create_api_blueprint()) is in order, to specify one API object per endpoint instead of one API object per /api/collectionname and all its sub-endpoints.

@daniel-j-h
Copy link

Bumping this issue, because I had to learn about it the hard way.

Has there been any progress towards solving this issue?

Without debug mode this raises an 500 HTTP error code, which - still - is not very nice.
Is there a sensible workaround in the meantime?

jfinkels added a commit that referenced this issue Feb 19, 2015
Before the behavior of Flask-Restless was a bit arbitrary. Now we force
it to comply with a concrete (though still changing) specification,
which can be found at http://jsonapi.org/.

This is a (severely) backwards-incompatible change, as it changes which
API endpoints are exposed and the format of requests and responses.

This fixes (or at least makes it much easier to fix or much easier to
mark as "won't fix") several issues, including but not limited to

  - #87
  - #153
  - #168
  - #193
  - #208
  - #211
  - #213
  - #243
  - #252
  - #253
  - #258
  - #261
  - #262
  - #303
  - #394
jfinkels added a commit that referenced this issue Feb 23, 2015
Previously, the behavior of Flask-Restless was a bit arbitrary. Now we
force it to comply with a concrete (though still changing)
specification, which can be found at http://jsonapi.org/.

This is a (severely) backwards-incompatible change, as it changes which
API endpoints are exposed and the format of requests and responses.

This change also moves JSON API compliance tests to a convenient
distinct test module, `tests.test_jsonapi.py`, so that compliance with
the specification can be easily verified. These tests correspond to
version 1.0rc2 of the JSON API specification, which can be found in
commit json-api/json-api@af5dfcc.

This change fixes (or at least makes it much easier to fix or much
easier to mark as "won't fix") quite a few issues, including but not
limited to

  - #87
  - #153
  - #168
  - #193
  - #208
  - #211
  - #213
  - #243
  - #252
  - #253
  - #258
  - #261
  - #262
  - #303
  - #394
jfinkels added a commit that referenced this issue Feb 24, 2015
Previously, the behavior of Flask-Restless was a bit arbitrary. Now we
force it to comply with a concrete (though still changing)
specification, which can be found at http://jsonapi.org/.

This is a (severely) backwards-incompatible change, as it changes which
API endpoints are exposed and the format of requests and responses.

This change also moves JSON API compliance tests to a convenient
distinct test module, `tests.test_jsonapi.py`, so that compliance with
the specification can be easily verified. These tests correspond to
version 1.0rc2 of the JSON API specification, which can be found in
commit json-api/json-api@af5dfcc.

This change fixes (or at least makes it much easier to fix or much
easier to mark as "won't fix") quite a few issues, including but not
limited to

  - #87
  - #153
  - #168
  - #193
  - #208
  - #211
  - #213
  - #243
  - #252
  - #253
  - #258
  - #261
  - #262
  - #303
  - #394
jfinkels added a commit that referenced this issue Mar 3, 2015
Previously, the behavior of Flask-Restless was a bit arbitrary. Now we
force it to comply with a concrete (though still changing)
specification, which can be found at http://jsonapi.org/.

This is a (severely) backwards-incompatible change, as it changes which
API endpoints are exposed and the format of requests and responses.

This change also moves JSON API compliance tests to a convenient
distinct test module, `tests.test_jsonapi.py`, so that compliance with
the specification can be easily verified. These tests correspond to
version 1.0rc2 of the JSON API specification, which can be found in
commit json-api/json-api@af5dfcc.

This change fixes (or at least makes it much easier to fix or much
easier to mark as "won't fix") quite a few issues, including but not
limited to

  - #87
  - #153
  - #168
  - #193
  - #208
  - #211
  - #213
  - #243
  - #252
  - #253
  - #258
  - #261
  - #262
  - #303
  - #394
jfinkels added a commit that referenced this issue Mar 5, 2015
Previously, the behavior of Flask-Restless was a bit arbitrary. Now we
force it to comply with a concrete (though still changing)
specification, which can be found at http://jsonapi.org/.

This is a (severely) backwards-incompatible change, as it changes which
API endpoints are exposed and the format of requests and responses.

This change also moves JSON API compliance tests to a convenient
distinct test module, `tests.test_jsonapi.py`, so that compliance with
the specification can be easily verified. These tests correspond to
version 1.0rc2 of the JSON API specification, which can be found in
commit json-api/json-api@af5dfcc.

This change fixes (or at least makes it much easier to fix or much
easier to mark as "won't fix") quite a few issues, including but not
limited to

  - #87
  - #153
  - #168
  - #193
  - #208
  - #211
  - #213
  - #243
  - #252
  - #253
  - #258
  - #261
  - #262
  - #303
  - #394
jfinkels added a commit that referenced this issue Mar 7, 2015
Previously, the behavior of Flask-Restless was a bit arbitrary. Now we
force it to comply with a concrete (though still changing)
specification, which can be found at http://jsonapi.org/.

This is a (severely) backwards-incompatible change, as it changes which
API endpoints are exposed and the format of requests and responses.

This change also moves JSON API compliance tests to a convenient
distinct test module, `tests.test_jsonapi.py`, so that compliance with
the specification can be easily verified. These tests correspond to
version 1.0rc2 of the JSON API specification, which can be found in
commit json-api/json-api@af5dfcc.

This change fixes (or at least makes it much easier to fix or much
easier to mark as "won't fix") quite a few issues, including but not
limited to

  - #87
  - #153
  - #168
  - #193
  - #208
  - #211
  - #213
  - #243
  - #252
  - #253
  - #258
  - #261
  - #262
  - #303
  - #394
jfinkels added a commit that referenced this issue Mar 8, 2015
Previously, the behavior of Flask-Restless was a bit arbitrary. Now we
force it to comply with a concrete (though still changing)
specification, which can be found at http://jsonapi.org/.

This is a (severely) backwards-incompatible change, as it changes which
API endpoints are exposed and the format of requests and responses.

This change also moves JSON API compliance tests to a convenient
distinct test module, `tests.test_jsonapi.py`, so that compliance with
the specification can be easily verified. These tests correspond to
version 1.0rc2 of the JSON API specification, which can be found in
commit json-api/json-api@af5dfcc.

This change fixes (or at least makes it much easier to fix or much
easier to mark as "won't fix") quite a few issues, including but not
limited to

  - #87
  - #153
  - #168
  - #193
  - #208
  - #211
  - #213
  - #243
  - #252
  - #253
  - #258
  - #261
  - #262
  - #303
  - #394
@jfinkels
Copy link
Owner

This is fixed on the master branch. You now get an error response with the message No such relation: "id"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants