GSoC — Phase 2
As mentioned in my last article, phase 1 ended with I creating a final PR for the searching mechanism.
On reviewing by mentors I got suggestions to refactor some code. It involved creating helper functions for tasks such as parsing search parameters and calculating offset and limit for pagination(commit). Besides that I also created an Exception class for invalid parameters, and finally the PR got merged(commit).
As discussed at the end of the last article, we had two features which were directly dependent on the implementation of IriTemplate .
- Client-controlled pagination and,
- Retrieval of nested collections.
1. Client-controlled pagination
To achieve this we needed to add functionality at hydrus so that client can pass paginated parameters like offset , limit , and pageIndex to hydrus and control how hydrus paginates the response.
It involved providing IriTemplateMappings for query fields like hydra:pageIndex , hydra:offset , and hydra:limit .
So basically hydrus attaches an IriTemplate having such variables to the collection response. With help of this IriTemplate, client creates request containing these pagination parameters and on receiving such request hydrus uses these parameters to paginate the response.
PR implementing this feature: https://github.com/HTTP-APIs/hydrus/pull/409
2. Retrieval of nested collections
This issue took highest effort in phase-2 and quite ironically it is not completely resolved as of now!
After having a basic discussion at #386, I created a PR(#406) to solve this issue. This PR used list of children at every parent instance to manage parent-child relations and added new endpoint of form api/collection/id/nestedCollection to serve nested collections. But as it had it’s own limitations(discussed on the PR itself), we started exploring other options. I hope we come up with something and resolve it within next few days.
Updating hydra-python-core with developments at Hydra
This task involved making hydra-python-core compatible with any APIDoc created using newly added parts of Hydra Spec (like hydra:manages, hydra:retunrsHeader , etc.).
As Gustavo had already compiled a list of such new additions and changes at #15 and I had already compiled a similar list in my proposal, I used them to identify needed changes and made appropriate changes in various files of hydra-python-core and opened PR #28 for the same.
Updating hydrus with changes made at hydra-python-core
Once I was done with updating hydra-python-core , the next task I had was to update hydrus to use latest hydra-python-core. Only tricky part here was changing of read-only and write-only to readable and writeable , as it had change of semantics, I had to changes old ApiDocs and also the code which used this properties for validation. While doing so I also added a new test for checking validation of readable properties. All changes can be found on PR #411.
Meanwhile I also opened a PR refactoring insert method of crud module(#413) and also updated Drone-Flock vocab at hydra-flock-vocab with new changes.
Ongoing
The main task right now is to resolve issue #386 at hydrus. Besides that, the other important task at hand is to add synchronization mechanism to hydrus(#300). More about that and other issues in the next article…
Good bye till then!
