Feature: new search modes

[nh916]

Description

added search mode:

• CHILD_NODE_TYPE_WITHIN_PARENT
  • search for all materials within a project
• CHILD_WITH_EXACT_NAME_WITHIN_PARENT
  • Returns the materials with that exact name in the project or nothing
• The only that remains is CHILD_CONTAINS_NAME_WITHIN_PARENT
  • because I am unsure of how to currently fit it into the SDK
  • trello ticket for it: https://trello.com/c/mSNPFHp8

Changes

• wrote new search mode in cript.API.search()
  • wrote documentation for new search mode in cript.API.search()
• added new search type to SearchMode enum
  • wrote documentation for it there
• wrote test for it
• wrote a new fixture that will get the cript project, turn it into a node, and give it to the test to use
  • the CRIPT project will exist on all environments of CRIPT
• giving good errors in case the value_to_search was required and the user forgot to input it
  • this way they are not left scratching their heads figuring out what is wrong and why the search result is empty

Screenshots

Not loving the new documentation examples back to back, but not sure what to do either
and the exception that it will raise is too long and could be beautified

Tests

• wrote integration tests for the 2 new search methods and both are passing

Known Issues

• pulling the CRIPT project from API and deserializing it takes a while
  • I think this is because we call _is_node_schema_valid() too many times, and when I just change that method to pass it speeds things up by a lot
• I don't love the way I have written the new search modes here because it is becoming big and all the error handling inside of each if is making it harder to read, hard to keep track of, and does not capture all error cases
  • This can be a jumping off point for now, but after this it will need a refactor
  • However, the way the code has been written makes adding a new endpoint a breeze!
• Some of the tests for search are a bit looser because each environment will have different things in the db so I cannot test the exact thing that will be returned in the exact order
  • so many times I am just checking that paginator has at least one thing that it was able to get
• Not really loving the documentation, but I think it will be usable for now until it is beautified

Notes

• The full documentation I made based off of the short API documentation to make understanding the new search modes clearer
• Removing @beartype for search for now because it causes more issues than it fixes

Checklist

• My name is on the list of contributors (CONTRIBUTORS.md) in the pull request source branch.
• I have updated the documentation to reflect my changes.

[trunk-io]

Merging to develop in this repository is managed by Trunk.

• To merge this pull request, check the box to the left or comment /trunk merge below.

[InnocentBug]

Can you lay out to me, why we need the searches with the parent?

You need the parent already present to use it with the SDK.
So, why use the API to fetch the children?

find_children does the same thing locally.
I don't see the need for this and it adds more complex codes.

Also if we offer two options to do the same thing, user get confused.

[InnocentBug]

ChildNodeTypeWithinParent

nodes = parent.find_children({"node": ["NodeType"]})

ChildNameWithinParent

nodes = parent.find_children({"name": "ChildName"})

[InnocentBug]

if you don't like the interface, write wrappers that internally call find_children.
But I think doing this locally is the better approach.

[nh916]

Can you lay out to me, why we need the searches with the parent?

You need the parent already present to use it with the SDK. So, why use the API to fetch the children?

find_children does the same thing locally. I don't see the need for this and it adds more complex codes.

Also if we offer two options to do the same thing, user get confused.

we don't have to have it, but I saw that the API endpoints exist so I thought lets put it into the SDK why not. I do agree that it does add more code, but it could be helpful. We can weigh the pros and cons and figure out if we want it or not, it's not a big deal to me.

Reasons why it could be helpful:

• The API currently responds with UUID and not the full node
  • Thus when searching through a project you might not get all the materials needed
    • I understand that the full project is coming, but I currently do not know when
• Giving the user multiple ways to search through the project gives us some safety in case one way of searching through the project fails, there is a backup method for searching through the project
• It is more efficient to get the API that has an efficient database to do the searching for us than to give it it to the SDK

[nh916]

lets make a decision on this soon because if we wait too long we might end up with a lot of merge conflicts

[InnocentBug]

I don't think I am the right person to make this decision.

[nh916]

@dylanwal can I get your thoughts on this? We are a bit stuck and not sure which decision would be best

[nh916]

@dylanwal feel free to correct if I'm wrong.

Basically the situation that we found is that @InnocentBug and I are both right and wrong, and our workflow could use improvements to be better and more efficient.

If the user is working with Project A and wants to use all the materials from Project B, they currently have to fetch the entire Project B with computation data file and more nodes, just to do a local search and to get the desired materials. This scenario would be inefficient.

However, the current scenario that I have coded is that I pull down the entire project node with computation data file and more nodes, and then use just the UUID to do an API search, which is also inefficient because I already have the full project node, so there is no need for another API call, I could just search through the project locally.

I think the ideal way of doing this is to maybe only get the bare project node with its basic attributes and nothing else, or just the UUID, and then using that to do the API search, so we can only get the materials and not have to pull down the entire node, but if we already have the entire node then a local search works better.

@InnocentBug does this make sense? what are your thoughts?