feat: add "POST ../access" & "PUT ../{access_id}"

[sarthakgupta072]

Description

Fixes #26 and #25

Type of change

Please delete options that are not relevant.

• New feature (non-breaking change which adds functionality)
• Documentation update

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• I have not reduced the existing code coverage
• I have added docstrings following the Python style guidelines of this project to all new modules, classes, methods and functions are documented with docstrings following; I have updated any previously existing docstrings, if applicable
• I have updated any sections of the app's documentation that are affected by the proposed changes, if applicable

[sarthakgupta072]

Hey @uniqueg. Tried something different in this code (not similar to POST and PUT in object registration). Please do have a look.

The main reason for this was that I was not able to cover some corner cases with other approaches that I had in mind. If you have any other ideas for implementation, please do suggest.

TIA :)

[uniqueg]

Thanks @sarthakgupta072. Should be able to look at this soon. But before I start: would you mind explaining in a bit more detail what you mean by "Tried something different" and "some corner cases"? Please also have a look at TRS-Filer where a very similar thing is already taken care of (objects & access methods vs tools & versions). Perhaps this will help. Not saying though that this is how it has to work. If you feel that your solution does the job and is elegant enough, I'll be happy to review that.

[sarthakgupta072]

Sure Alex. Will have a look and update you soon. ;)

[sarthakgupta072]

Hey @uniqueg. I'll just compare both trs-filer approach, and the approach used by me.

Consider the case, where the id of (access_method/version) is provided, but it is not already there in the (object/tool). In trs-filer, we are using a while loop to generate unique ids for versions, so that even if there is not a unique id available, it will be made available in the next few iterations, but in my case, I am beforehand generating a unique id and inserting the access_method in the drs object.

Now, when I analyze both the approaches, I feel the approach in trs-filer is much better in terms of time complexity and follows the Python principle of EAFP.

So, I'll make changes according to trs-filer repo, which will also maintain consistency between both code bases of trs-filer and drs-filer. 😄

[uniqueg]

Sounds great, thanks a lot!

[sarthakgupta072]

Hey @uniqueg. Implemented this just like trs-filer. Please have a look. 🙂

I'll add tests if everything looks good.

[uniqueg]

Thanks @sarthakgupta072 and sorry for the looong wait. It looks fine to me at first glance, but I didn't give an in-depth review. I'd say that if manual functional/integration tests pass (i.e., check that you can add/edit access methods and the controllers behave as expected), I think you can go ahead with writing unit tests.

Added two minor comments, a typo and replacing a function with an import from FOCA (less to unit test)

[uniqueg]

Create an access method

[uniqueg]

I think you can import that function from FOCA now, it should be available in 0.6.0