I passed the second evaluation in GSoC 2020. Hurray!
Also, now 10 weeks have been completed. We are in the endgame now.
Now coming to what I have been working on the last two weeks. The last two weeks were mainly spent in tackling a very big pending issue in
hydrus, hydrus hardcoded with ‘vocab:’ to find relationships issue.
At the moment,
hydrus has been hardcoded with
vocab: while it tries to identify foreign key relationship. For eg, here.
But the problem here is that just expanding
vocab: won’t solve the underlying issue for discovering all foreign key relationships correctly. For example, we could as well have something called
@context node of the Hydra API doc and then that could be used to reference something like
We might also extract this correctly after some work at parsing the API doc. But if suppose our context becomes nested, it will become difficult to parse.
This was a really big issue to tackle, not just because of the implementation in
hydrus but also because there were a lot of changes required in the
hydra-python-core repo. That is because the hard coded nature of
hydrus was due to to the fact that initially
hydra-python-core were very tightly coupled.
The ideal behaviour should be that,
hydrus starts with an expanded API doc. We should not parse the API doc without expanding it beforehand. This change should then ideally take place it the
hydra_python_core library, which generates the API doc object which
hydrus uses for parsing data required of the API doc. Therefore the output of the
doc_maker module should be an API doc which is expanded beforehand.
This dependency on the
hydra-python-core made this issue a little more difficult than I initally anticipated.
Other than working on the above issue, I spent some time adding documentation on
hydrus here. We all know how important good documentation is for any project, especially open source projects.
Also, there was some work needed to be done on the previous Treating collections as a resource issue.
Basically, some work had to be done on GET request on any
/collection endpoint here. This work was basically an update on the work in this PR.
As most of the work done in this period was dependent on
hydra-python-core, I really learnt how to work in a team, alongside fellow GSoCer at HydraEcocsystem, Priyanshu.
It was an amazing experience as together both of us hunted down all the bugs to make sure
hydra-python-core work in sync perfectly.
My PRs in this period:
- Remove hardcoded
vocab:keyword - PR #490
- Add docs on
hydrus- PR #49
- GET request on
/collectionendpoint - PR #492
After PR #488 got merged,
hydrus will has support for treating collections as a resource.
But in that implementation, collections are restricted to only a collection of a single type class.
As described in the spec, collections are described as a ‘set of somehow related resources’. This would also mean that a collection might also be a set of classes of different types.
We need to add support for this type of collections too.