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

BANDWIDTH_SAVER no longer works with resolve_resource_projection #1338

Closed
hlongmore opened this issue Dec 14, 2019 · 4 comments
Closed

BANDWIDTH_SAVER no longer works with resolve_resource_projection #1338

hlongmore opened this issue Dec 14, 2019 · 4 comments
Labels

Comments

@hlongmore
Copy link
Contributor

if config.BANDWIDTH_SAVER:

The sense of the conditional

    if config.BANDWIDTH_SAVER:
        return

makes the BANDWIDTH_SAVER have no effect, as all of the document fields get removed, unless one has all the fields in the projection.

Example:

POST http://localhost:5000/rules
Accept: application/json
Content-Type: application/json
Cache-Control: no-cache

[
  {
    "name": "Jaguar Jumps",
    "start": "2019-12-13T00:14:22.773Z",
    "duration": "weeks",
    "expires": true,
  },
  {
    "name": "Koala Kandy",
    "start": "2019-12-13T00:14:22.773Z",
    "duration": "weeks",
    "expires": true,
  }
]

results in only the auto processed fields. If I force-jump while debugging to skip to the return statement on the second one, I get the expected entire document. Below is what I get with that skip to the return:

{
  "_status": "OK",
  "_items": [
    {
      "_id": "5df420a8a9d79a0301ef5cad",
      "_created": "1970-01-01T00:00:00 ",
      "_updated": "1970-01-01T00:00:00 ",
      "_etag": "d000c9a42314a7fb8e8961911a5c66f78a18bfb7",
      "_links": {
        "self": {
          "title": "Rule",
          "href": "rules/5df420a8a9d79a0301ef5cad"
        }
      },
      "_status": "OK"
    },
    {
      "name": "Koala Kandy",
      "start": "2019-12-13T00:14:22 UTC",
      "duration": "weeks",
      "expires": true,
      "_updated": "2019-12-13T23:35:39 ",
      "_created": "2019-12-13T23:35:39 ",
      "_etag": "4a83a54e30cd0a097722d91cd8bf82a121d8198a",
      "_id": "5df420a8a9d79a0301ef5cae",
      "_links": {
        "self": {
          "title": "Rule",
          "href": "rules/5df420a8a9d79a0301ef5cae"
        },
      },
      "_status": "OK"
    }
  ]
}

Python version: 3.7.1
Eve version: 0.9.2
Schema:

rules = {
    'allow_unknown': True,
    'schema': {
        'name': {
            'type': 'string',
        },
        'start': {
            'type': 'datetime',
            'required': True,
            'coerce': to_datetime,
        },
        'duration': {
            'type': 'string',
            'allowed': ['days', 'weeks', 'months', 'years', 'one-time'],
            'required': True,
        },
        'expires': {
            'type': 'boolean',
            'default': False,
        },
    },
}
@nicolaiarocci
Copy link
Member

Not sure I get what you mean. Per BANDWIDTH_SAVER documentation:

When True, POST, PUT, and PATCH responses only return automatically handled fields and EXTRA_RESPONSE_FIELDS. When False, the entire document will be sent. Defaults to True.

Which seems coherent with the behavior you are getting.

@hlongmore
Copy link
Contributor Author

Sorry, I muddied the waters by including the output from my debug session. With BANDWIDTH_SAVER set to False, the first document, before I did the force-jump, is missing the fields ["name", "start", "duration", "expires"]; the second document, after the force-jump, has those fields as well as the automatically handled fields. Without the force-jump, they would have both been missing those fields.

hlongmore added a commit to hlongmore/eve that referenced this issue Mar 31, 2020
Fix for pyeve#1338

Uncommented and updated unit tests
Updated CONTRIBUTING.rst
nicolaiarocci pushed a commit that referenced this issue Apr 4, 2020
Fix for #1338

Uncommented and updated unit tests
Updated CONTRIBUTING.rst
@stale
Copy link

stale bot commented Jul 3, 2020

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

@stale stale bot added the stale label Jul 3, 2020
@hlongmore
Copy link
Contributor Author

Since @nicolaiarocci merged this to master, and was able to resolve the travis failures by pinning the flask version, I'm closing this issue.

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

2 participants