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

Allow HTTP delete of sub resources #193

Closed
chrismckinnel opened this issue Apr 29, 2013 · 7 comments
Labels

Comments

@chrismckinnel
Copy link
Contributor

@chrismckinnel chrismckinnel commented Apr 29, 2013

At the moment we have to do something like:

PATCH /model/<id> 

"relation": {
    "remove": [
        {
            "parent_id": 1,
            "child_id": 1,
            "__delete__": True
        }
    ]
}

To delete a many to many relation. Perhaps this has changed slightly on the master branch, but I'm still using the latest tagged release.

Wouldn't it make more sense to be able to a simple:

DELETE /model/<id>/relation/<id>

Seems like it would simplify things a bit.

Thoughts?

@jfinkels

This comment has been minimized.

Copy link
Owner

@jfinkels jfinkels commented May 1, 2013

Hmm, it's a possibility. I suppose I could be convinced of this. Let me think about it. I'm happy to hear more opinions.

@jfinkels

This comment has been minimized.

Copy link
Owner

@jfinkels jfinkels commented May 20, 2013

It occurs to me that perhaps the client shouldn't be given access to the __delete__ power; this should be configured in the database as a cascade rule.

@chrismckinnel

This comment has been minimized.

Copy link
Contributor Author

@chrismckinnel chrismckinnel commented May 20, 2013

How would you delete the relation then? The cascade would only delete the many to many entry in the DB if it's parent object was deleted, right?

jfinkels added a commit that referenced this issue May 20, 2013
Allows DELETE requests to URLs representing related instances of a model,
thereby removing that related instance from the relation.
@jfinkels

This comment has been minimized.

Copy link
Owner

@jfinkels jfinkels commented May 20, 2013

Oh, I suppose delete-orphan only makes sense when being used with a one-to-many relation (for example, when I remove a child from a parent [parent.children.remove(child)], delete the child because it as an orphaned object).

My concern is this: what if the client __delete__s a related instance that may still be related to other instances? Would that leave the database in an inconsistent state?

@chrismckinnel

This comment has been minimized.

Copy link
Contributor Author

@chrismckinnel chrismckinnel commented May 20, 2013

If the delete cascades and primary/foreign key constraints are set on the DB / in the models correctly it wouldn't be a problem as the child and all it's related entries in the DB would be deleted.

If the delete cascade wasn't set in the models, I think session.commit() attempts to set the primary key values in the DB to NULL.

If the constraints aren't set correctly in the DB, that's when we'd get an inconsistent state with relations pointing to non-existent parent instances.

Removing the ability to use __delete__ would force people to have correct delete cascades and DB constraints, right? Can't be a bad thing?

@jfinkels

This comment has been minimized.

Copy link
Owner

@jfinkels jfinkels commented May 20, 2013

I think that's correct, so __delete__ functionality should be removed. However, it may be superseded by a more robust relationship URL specification as described in #208, if that gets implemented.

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

This comment has been minimized.

Copy link
Owner

@jfinkels jfinkels commented Feb 12, 2016

This is now handled according to the JSON API protocol: http://flask-restless.readthedocs.org/en/latest/updatingrelationships.html

@jfinkels jfinkels closed this Feb 12, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.