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

Convert old rest stack: supremm module #28

Merged
merged 1 commit into from
Apr 11, 2017

Conversation

jsperhac
Copy link
Contributor

@jsperhac jsperhac commented Mar 23, 2017

This is a step along the way toward killing off the old REST stack.

Description

Create a NewRest-style controller for the internal dashboard's supremm dataflow functionality, to replace the old classes/REST/supremm code.

Refer to pull requests against

Motivation and Context

  • Head in the direction of reducing 3 rest stacks to 2 rest stacks
  • I'm tired of duplicate code.

Tests performed

Changes are limited to the internal dashboard's supremm dataflow, which reports on the last time various supremm sources contributed data. These were tested by hand to verify, using chrome debugger to observe which rest endpoints are in use. Finally, tests for the new endpoints have been added and use the integration test harness.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • My code follows the code style of this project as found in the CONTRIBUTING document.
  • I have added tests to cover my changes.
  • All new and existing tests passed.

Caveats:

More things I'd like to do related to the rest stacks (but not a part of the current pull request):

  • Introduce improved logging for the NewRest controllers

To Do:

Remaining to do in this exercise:

  • see pull requests named "convert-old-rest-stack" for appkernel and base xdmod modules.
  • following merging of the convert-old-rest-stack pull requests, delete entire contents of REST/, and review the contents of libraries/rest.php. This will be addressed in a subsequent pull request.
  • Move this and other iframes in the internal dashboard into proper tabs. (And: Review ~duplicated code such as internal_dashboard/user_check.php and internal_dashboard/supremm/user_check.php.) This should be addressed in a separate pull request.

} else {
$payload['message'] = self::_DEFAULT_ERROR_MESSAGE;
}
} catch (BadRequestHttpException $e) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it necessary to catch all of these exceptions? Surely the middleware should handle this for you automatically.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is modeled rather heavily on the other NewRest controllers, which similarly catch lots of exceptions. I will review...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exception code has been removed; framework handles this, as you point out!

->get("$root/dbstats", "$base::getDbstats")
->assert('resource_id', '(\w|_|-])+')
->convert('db_id', "$conversions::toInt")
->convert('resource_id', "$conversions::toString");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This definition says that db_id is an int and resource_id is a string, but on lines 123 and 124 you require the exact opposite: get db_id must be a string and resource_id must be an int.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup, it's wrong here, I will fix. Maybe changing the variable name will also help clarify this.

} catch (HttpException $e) {
$payload['message'] = $e->getMessage();
$statusCode = $e->getStatusCode();
} catch (\Exception $e) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If authorize() throws an AccessDeniedException then this code will catch it and change the status code to internal error. This is wrong.

I think that you should not be catching exceptions here. Instead let the framework handle them

* @param timestamp $ts
* @return mixed
*/
private function _time2str($ts)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like this should be a utility function that anything can use. Maybe even remove this from the backend code and use something like moment in the frontend to do this as a display thing...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the moment the idea is to port what's there. Moving general functionality into utility functions should absolutely be done separately...

* @param numeric $d
* @return mixed
*/
private function _formatDataSize($d)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This as well seems like a utility function that is able to be used in multiple places.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As mentioned above, yes, I agree--in a separate pull request.

@plessbd
Copy link
Contributor

plessbd commented Mar 23, 2017

I think it would help to run the code through phpcbf to fix a bunch of the warnings and errors from travis ci.

@jsperhac
Copy link
Contributor Author

And I missed that travis ci failed. OK, I'll revisit. Thanks.

<script type="text/javascript" src="/gui/lib/extjs/ext-all-debug.js"></script>

<!-- RESTProxy -->
<script type="text/javascript" src="../../gui/js/CCR.js"></script>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are you including the REST.js RESTProxy and CCR.js javascript files? They are not needed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe you are right...duly noted, I'll remove those includes.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@jsperhac jsperhac dismissed plessbd’s stale review March 30, 2017 14:50

Moving utility/format functions will be done in a separate pull request.

@jsperhac
Copy link
Contributor Author

In order for integration tests to work, the fix-framework-authorize-exceptions branch on xdmod repo will be needed (pull request to follow once unit tests exist)

@plessbd
Copy link
Contributor

plessbd commented Apr 11, 2017

Existing travis CI Errors will be fixed by #35 and an update to https://github.com/jpwhite4/lint-diff

@plessbd plessbd mentioned this pull request Apr 11, 2017
6 tasks
…wRest stack,

to enable elimination of old REST stack code.
@jpwhite4 jpwhite4 merged commit d7558a2 into ubccr:xdmod6.6 Apr 11, 2017
@tyearke tyearke added this to the v6.6.0 milestone Apr 12, 2017
@tyearke tyearke added the qa label Apr 12, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants